2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* dvb_frontend.c: DVB frontend tuning interface/thread
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* Copyright (C) 1999-2001 Ralph Metzler
|
|
|
|
* Marcus Metzler
|
|
|
|
* Holger Waechtler
|
|
|
|
* for convergence integrated media GmbH
|
|
|
|
*
|
|
|
|
* Copyright (C) 2004 Andrew de Quincey (tuning thread cleanup)
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
* Or, point your browser to http://www.gnu.org/copyleft/gpl.html
|
|
|
|
*/
|
|
|
|
|
2011-12-27 07:22:50 +08:00
|
|
|
/* Enables DVBv3 compatibility bits at the headers */
|
|
|
|
#define __DVB_CORE__
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/wait.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/poll.h>
|
2009-12-02 05:17:41 +08:00
|
|
|
#include <linux/semaphore.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/list.h>
|
2006-12-07 12:34:23 +08:00
|
|
|
#include <linux/freezer.h>
|
2005-06-24 13:02:39 +08:00
|
|
|
#include <linux/jiffies.h>
|
2007-02-09 01:32:43 +08:00
|
|
|
#include <linux/kthread.h>
|
2015-05-31 15:17:06 +08:00
|
|
|
#include <linux/ktime.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/processor.h>
|
|
|
|
|
|
|
|
#include "dvb_frontend.h"
|
|
|
|
#include "dvbdev.h"
|
2008-09-26 11:29:49 +08:00
|
|
|
#include <linux/dvb/version.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
static int dvb_frontend_debug;
|
2007-08-25 23:22:16 +08:00
|
|
|
static int dvb_shutdown_timeout;
|
2005-04-17 06:20:36 +08:00
|
|
|
static int dvb_force_auto_inversion;
|
|
|
|
static int dvb_override_tune_delay;
|
|
|
|
static int dvb_powerdown_on_sleep = 1;
|
2008-10-11 22:44:05 +08:00
|
|
|
static int dvb_mfe_wait_time = 5;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
module_param_named(frontend_debug, dvb_frontend_debug, int, 0644);
|
2005-05-17 12:54:21 +08:00
|
|
|
MODULE_PARM_DESC(frontend_debug, "Turn on/off frontend core debugging (default:off).");
|
2006-02-27 11:09:32 +08:00
|
|
|
module_param(dvb_shutdown_timeout, int, 0644);
|
2005-04-17 06:20:36 +08:00
|
|
|
MODULE_PARM_DESC(dvb_shutdown_timeout, "wait <shutdown_timeout> seconds after close() before suspending hardware");
|
2006-02-27 11:09:32 +08:00
|
|
|
module_param(dvb_force_auto_inversion, int, 0644);
|
2005-04-17 06:20:36 +08:00
|
|
|
MODULE_PARM_DESC(dvb_force_auto_inversion, "0: normal (default), 1: INVERSION_AUTO forced always");
|
2006-02-27 11:09:32 +08:00
|
|
|
module_param(dvb_override_tune_delay, int, 0644);
|
2005-04-17 06:20:36 +08:00
|
|
|
MODULE_PARM_DESC(dvb_override_tune_delay, "0: normal (default), >0 => delay in milliseconds to wait for lock after a tune attempt");
|
2006-02-27 11:09:32 +08:00
|
|
|
module_param(dvb_powerdown_on_sleep, int, 0644);
|
2006-04-11 21:21:37 +08:00
|
|
|
MODULE_PARM_DESC(dvb_powerdown_on_sleep, "0: do not power down, 1: turn LNB voltage off on sleep (default)");
|
2008-10-11 22:44:05 +08:00
|
|
|
module_param(dvb_mfe_wait_time, int, 0644);
|
|
|
|
MODULE_PARM_DESC(dvb_mfe_wait_time, "Wait up to <mfe_wait_time> seconds on open() for multi-frontend to become available (default:5 seconds)");
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#define FESTATE_IDLE 1
|
|
|
|
#define FESTATE_RETUNE 2
|
|
|
|
#define FESTATE_TUNING_FAST 4
|
|
|
|
#define FESTATE_TUNING_SLOW 8
|
|
|
|
#define FESTATE_TUNED 16
|
|
|
|
#define FESTATE_ZIGZAG_FAST 32
|
|
|
|
#define FESTATE_ZIGZAG_SLOW 64
|
|
|
|
#define FESTATE_DISEQC 128
|
2009-09-02 06:23:09 +08:00
|
|
|
#define FESTATE_ERROR 256
|
2005-04-17 06:20:36 +08:00
|
|
|
#define FESTATE_WAITFORLOCK (FESTATE_TUNING_FAST | FESTATE_TUNING_SLOW | FESTATE_ZIGZAG_FAST | FESTATE_ZIGZAG_SLOW | FESTATE_DISEQC)
|
|
|
|
#define FESTATE_SEARCHING_FAST (FESTATE_TUNING_FAST | FESTATE_ZIGZAG_FAST)
|
|
|
|
#define FESTATE_SEARCHING_SLOW (FESTATE_TUNING_SLOW | FESTATE_ZIGZAG_SLOW)
|
|
|
|
#define FESTATE_LOSTLOCK (FESTATE_ZIGZAG_FAST | FESTATE_ZIGZAG_SLOW)
|
2006-06-21 21:27:31 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* FESTATE_IDLE. No tuning parameters have been supplied and the loop is idling.
|
|
|
|
* FESTATE_RETUNE. Parameters have been supplied, but we have not yet performed the first tune.
|
|
|
|
* FESTATE_TUNING_FAST. Tuning parameters have been supplied and fast zigzag scan is in progress.
|
|
|
|
* FESTATE_TUNING_SLOW. Tuning parameters have been supplied. Fast zigzag failed, so we're trying again, but slower.
|
|
|
|
* FESTATE_TUNED. The frontend has successfully locked on.
|
|
|
|
* FESTATE_ZIGZAG_FAST. The lock has been lost, and a fast zigzag has been initiated to try and regain it.
|
|
|
|
* FESTATE_ZIGZAG_SLOW. The lock has been lost. Fast zigzag has been failed, so we're trying again, but slower.
|
|
|
|
* FESTATE_DISEQC. A DISEQC command has just been issued.
|
|
|
|
* FESTATE_WAITFORLOCK. When we're waiting for a lock.
|
|
|
|
* FESTATE_SEARCHING_FAST. When we're searching for a signal using a fast zigzag scan.
|
|
|
|
* FESTATE_SEARCHING_SLOW. When we're searching for a signal using a slow zigzag scan.
|
|
|
|
* FESTATE_LOSTLOCK. When the lock has been lost, and we're searching it again.
|
|
|
|
*/
|
|
|
|
|
2006-02-07 16:49:14 +08:00
|
|
|
static DEFINE_MUTEX(frontend_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
struct dvb_frontend_private {
|
|
|
|
|
2006-01-10 01:25:07 +08:00
|
|
|
/* thread/frontend values */
|
2005-04-17 06:20:36 +08:00
|
|
|
struct dvb_device *dvbdev;
|
2011-05-09 07:03:40 +08:00
|
|
|
struct dvb_frontend_parameters parameters_out;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct dvb_fe_events events;
|
|
|
|
struct semaphore sem;
|
|
|
|
struct list_head list_head;
|
|
|
|
wait_queue_head_t wait_queue;
|
2007-02-09 01:32:43 +08:00
|
|
|
struct task_struct *thread;
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned long release_jiffies;
|
2006-01-10 01:25:07 +08:00
|
|
|
unsigned int wakeup;
|
2015-06-08 01:53:52 +08:00
|
|
|
enum fe_status status;
|
2006-01-10 01:32:43 +08:00
|
|
|
unsigned long tune_mode_flags;
|
2006-01-10 01:25:07 +08:00
|
|
|
unsigned int delay;
|
2006-03-31 02:53:35 +08:00
|
|
|
unsigned int reinitialise;
|
2006-04-07 01:32:23 +08:00
|
|
|
int tone;
|
|
|
|
int voltage;
|
2006-01-10 01:25:07 +08:00
|
|
|
|
|
|
|
/* swzigzag values */
|
|
|
|
unsigned int state;
|
|
|
|
unsigned int bending;
|
|
|
|
int lnb_drift;
|
|
|
|
unsigned int inversion;
|
|
|
|
unsigned int auto_step;
|
|
|
|
unsigned int auto_sub_step;
|
|
|
|
unsigned int started_auto_step;
|
|
|
|
unsigned int min_delay;
|
|
|
|
unsigned int max_drift;
|
|
|
|
unsigned int step_size;
|
|
|
|
int quality;
|
|
|
|
unsigned int check_wrapped;
|
2008-10-15 03:34:07 +08:00
|
|
|
enum dvbfe_search algo_status;
|
2015-01-07 04:53:15 +08:00
|
|
|
|
|
|
|
#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
|
|
|
|
struct media_pipeline pipe;
|
|
|
|
struct media_entity *pipe_start_entity;
|
|
|
|
#endif
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2006-03-31 02:53:35 +08:00
|
|
|
static void dvb_frontend_wakeup(struct dvb_frontend *fe);
|
2011-12-23 01:47:48 +08:00
|
|
|
static int dtv_get_frontend(struct dvb_frontend *fe,
|
|
|
|
struct dvb_frontend_parameters *p_out);
|
2012-04-07 05:38:18 +08:00
|
|
|
static int dtv_property_legacy_params_sync(struct dvb_frontend *fe,
|
|
|
|
struct dvb_frontend_parameters *p);
|
2011-12-23 01:47:48 +08:00
|
|
|
|
|
|
|
static bool has_get_frontend(struct dvb_frontend *fe)
|
|
|
|
{
|
2012-03-27 23:53:19 +08:00
|
|
|
return fe->ops.get_frontend != NULL;
|
2011-12-23 01:47:48 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
/*
|
|
|
|
* Due to DVBv3 API calls, a delivery system should be mapped into one of
|
|
|
|
* the 4 DVBv3 delivery systems (FE_QPSK, FE_QAM, FE_OFDM or FE_ATSC),
|
|
|
|
* otherwise, a DVBv3 call will fail.
|
|
|
|
*/
|
|
|
|
enum dvbv3_emulation_type {
|
|
|
|
DVBV3_UNKNOWN,
|
|
|
|
DVBV3_QPSK,
|
|
|
|
DVBV3_QAM,
|
|
|
|
DVBV3_OFDM,
|
|
|
|
DVBV3_ATSC,
|
|
|
|
};
|
|
|
|
|
|
|
|
static enum dvbv3_emulation_type dvbv3_type(u32 delivery_system)
|
|
|
|
{
|
|
|
|
switch (delivery_system) {
|
|
|
|
case SYS_DVBC_ANNEX_A:
|
|
|
|
case SYS_DVBC_ANNEX_C:
|
|
|
|
return DVBV3_QAM;
|
|
|
|
case SYS_DVBS:
|
|
|
|
case SYS_DVBS2:
|
|
|
|
case SYS_TURBO:
|
|
|
|
case SYS_ISDBS:
|
|
|
|
case SYS_DSS:
|
|
|
|
return DVBV3_QPSK;
|
|
|
|
case SYS_DVBT:
|
|
|
|
case SYS_DVBT2:
|
|
|
|
case SYS_ISDBT:
|
2012-08-13 09:33:21 +08:00
|
|
|
case SYS_DTMB:
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
return DVBV3_OFDM;
|
|
|
|
case SYS_ATSC:
|
2012-01-30 02:44:58 +08:00
|
|
|
case SYS_ATSCMH:
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
case SYS_DVBC_ANNEX_B:
|
|
|
|
return DVBV3_ATSC;
|
|
|
|
case SYS_UNDEFINED:
|
|
|
|
case SYS_ISDBC:
|
|
|
|
case SYS_DVBH:
|
|
|
|
case SYS_DAB:
|
|
|
|
default:
|
|
|
|
/*
|
|
|
|
* Doesn't know how to emulate those types and/or
|
|
|
|
* there's no frontend driver from this type yet
|
|
|
|
* with some emulation code, so, we're not sure yet how
|
|
|
|
* to handle them, or they're not compatible with a DVBv3 call.
|
|
|
|
*/
|
|
|
|
return DVBV3_UNKNOWN;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-08 01:53:52 +08:00
|
|
|
static void dvb_frontend_add_event(struct dvb_frontend *fe,
|
|
|
|
enum fe_status status)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct dvb_fe_events *events = &fepriv->events;
|
|
|
|
struct dvb_frontend_event *e;
|
|
|
|
int wp;
|
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s:\n", __func__);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-12-23 01:47:48 +08:00
|
|
|
if ((status & FE_HAS_LOCK) && has_get_frontend(fe))
|
[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>
2011-12-30 22:30:21 +08:00
|
|
|
dtv_get_frontend(fe, &fepriv->parameters_out);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-08-04 23:33:15 +08:00
|
|
|
mutex_lock(&events->mtx);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-08-04 23:33:15 +08:00
|
|
|
wp = (events->eventw + 1) % MAX_EVENT;
|
2005-04-17 06:20:36 +08:00
|
|
|
if (wp == events->eventr) {
|
|
|
|
events->overflow = 1;
|
|
|
|
events->eventr = (events->eventr + 1) % MAX_EVENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
e = &events->events[events->eventw];
|
2011-08-04 23:33:15 +08:00
|
|
|
e->status = status;
|
2011-05-09 07:03:40 +08:00
|
|
|
e->parameters = fepriv->parameters_out;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
events->eventw = wp;
|
|
|
|
|
2007-07-31 01:58:10 +08:00
|
|
|
mutex_unlock(&events->mtx);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
wake_up_interruptible (&events->wait_queue);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dvb_frontend_get_event(struct dvb_frontend *fe,
|
|
|
|
struct dvb_frontend_event *event, int flags)
|
|
|
|
{
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct dvb_fe_events *events = &fepriv->events;
|
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s:\n", __func__);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (events->overflow) {
|
|
|
|
events->overflow = 0;
|
|
|
|
return -EOVERFLOW;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (events->eventw == events->eventr) {
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (flags & O_NONBLOCK)
|
|
|
|
return -EWOULDBLOCK;
|
|
|
|
|
|
|
|
up(&fepriv->sem);
|
|
|
|
|
|
|
|
ret = wait_event_interruptible (events->wait_queue,
|
|
|
|
events->eventw != events->eventr);
|
|
|
|
|
|
|
|
if (down_interruptible (&fepriv->sem))
|
|
|
|
return -ERESTARTSYS;
|
|
|
|
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2011-08-04 23:33:15 +08:00
|
|
|
mutex_lock(&events->mtx);
|
|
|
|
*event = events->events[events->eventr];
|
2005-04-17 06:20:36 +08:00
|
|
|
events->eventr = (events->eventr + 1) % MAX_EVENT;
|
2007-07-31 01:58:10 +08:00
|
|
|
mutex_unlock(&events->mtx);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-08-04 23:33:14 +08:00
|
|
|
static void dvb_frontend_clear_events(struct dvb_frontend *fe)
|
|
|
|
{
|
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
|
|
|
struct dvb_fe_events *events = &fepriv->events;
|
|
|
|
|
|
|
|
mutex_lock(&events->mtx);
|
|
|
|
events->eventr = events->eventw;
|
|
|
|
mutex_unlock(&events->mtx);
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static void dvb_frontend_init(struct dvb_frontend *fe)
|
|
|
|
{
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device,
|
|
|
|
"%s: initialising adapter %i frontend %i (%s)...\n",
|
|
|
|
__func__, fe->dvb->num, fe->id, fe->ops.info.name);
|
2006-05-14 16:01:31 +08:00
|
|
|
|
|
|
|
if (fe->ops.init)
|
|
|
|
fe->ops.init(fe);
|
|
|
|
if (fe->ops.tuner_ops.init) {
|
2008-10-21 05:14:14 +08:00
|
|
|
if (fe->ops.i2c_gate_ctrl)
|
|
|
|
fe->ops.i2c_gate_ctrl(fe, 1);
|
2006-05-14 16:01:31 +08:00
|
|
|
fe->ops.tuner_ops.init(fe);
|
|
|
|
if (fe->ops.i2c_gate_ctrl)
|
|
|
|
fe->ops.i2c_gate_ctrl(fe, 0);
|
2006-04-19 04:47:09 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2006-03-31 02:53:35 +08:00
|
|
|
void dvb_frontend_reinitialise(struct dvb_frontend *fe)
|
|
|
|
{
|
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
|
|
|
|
|
|
|
fepriv->reinitialise = 1;
|
|
|
|
dvb_frontend_wakeup(fe);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dvb_frontend_reinitialise);
|
|
|
|
|
2006-01-10 01:25:07 +08:00
|
|
|
static void dvb_frontend_swzigzag_update_delay(struct dvb_frontend_private *fepriv, int locked)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2006-01-10 01:25:07 +08:00
|
|
|
int q2;
|
2012-08-16 07:28:37 +08:00
|
|
|
struct dvb_frontend *fe = fepriv->dvbdev->priv;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s:\n", __func__);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-01-10 01:25:07 +08:00
|
|
|
if (locked)
|
|
|
|
(fepriv->quality) = (fepriv->quality * 220 + 36*256) / 256;
|
|
|
|
else
|
|
|
|
(fepriv->quality) = (fepriv->quality * 220 + 0) / 256;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-01-10 01:25:07 +08:00
|
|
|
q2 = fepriv->quality - 128;
|
|
|
|
q2 *= q2;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-01-10 01:25:07 +08:00
|
|
|
fepriv->delay = fepriv->min_delay + q2 * HZ / (128*128);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Performs automatic twiddling of frontend parameters.
|
|
|
|
*
|
|
|
|
* @param fe The frontend concerned.
|
|
|
|
* @param check_wrapped Checks if an iteration has completed. DO NOT SET ON THE FIRST ATTEMPT
|
|
|
|
* @returns Number of complete iterations that have been performed.
|
|
|
|
*/
|
2006-01-10 01:25:07 +08:00
|
|
|
static int dvb_frontend_swzigzag_autotune(struct dvb_frontend *fe, int check_wrapped)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int autoinversion;
|
|
|
|
int ready = 0;
|
2009-09-02 06:23:09 +08:00
|
|
|
int fe_set_err = 0;
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2011-12-30 20:30:25 +08:00
|
|
|
struct dtv_frontend_properties *c = &fe->dtv_property_cache, tmp;
|
|
|
|
int original_inversion = c->inversion;
|
|
|
|
u32 original_frequency = c->frequency;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* are we using autoinversion? */
|
2006-05-14 16:01:31 +08:00
|
|
|
autoinversion = ((!(fe->ops.info.caps & FE_CAN_INVERSION_AUTO)) &&
|
2011-12-30 20:30:25 +08:00
|
|
|
(c->inversion == INVERSION_AUTO));
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* setup parameters correctly */
|
|
|
|
while(!ready) {
|
|
|
|
/* calculate the lnb_drift */
|
|
|
|
fepriv->lnb_drift = fepriv->auto_step * fepriv->step_size;
|
|
|
|
|
|
|
|
/* wrap the auto_step if we've exceeded the maximum drift */
|
|
|
|
if (fepriv->lnb_drift > fepriv->max_drift) {
|
|
|
|
fepriv->auto_step = 0;
|
|
|
|
fepriv->auto_sub_step = 0;
|
|
|
|
fepriv->lnb_drift = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* perform inversion and +/- zigzag */
|
|
|
|
switch(fepriv->auto_sub_step) {
|
|
|
|
case 0:
|
|
|
|
/* try with the current inversion and current drift setting */
|
|
|
|
ready = 1;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 1:
|
|
|
|
if (!autoinversion) break;
|
|
|
|
|
|
|
|
fepriv->inversion = (fepriv->inversion == INVERSION_OFF) ? INVERSION_ON : INVERSION_OFF;
|
|
|
|
ready = 1;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 2:
|
|
|
|
if (fepriv->lnb_drift == 0) break;
|
|
|
|
|
|
|
|
fepriv->lnb_drift = -fepriv->lnb_drift;
|
|
|
|
ready = 1;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 3:
|
|
|
|
if (fepriv->lnb_drift == 0) break;
|
|
|
|
if (!autoinversion) break;
|
|
|
|
|
|
|
|
fepriv->inversion = (fepriv->inversion == INVERSION_OFF) ? INVERSION_ON : INVERSION_OFF;
|
|
|
|
fepriv->lnb_drift = -fepriv->lnb_drift;
|
|
|
|
ready = 1;
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
fepriv->auto_step++;
|
|
|
|
fepriv->auto_sub_step = -1; /* it'll be incremented to 0 in a moment */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ready) fepriv->auto_sub_step++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* if this attempt would hit where we started, indicate a complete
|
|
|
|
* iteration has occurred */
|
|
|
|
if ((fepriv->auto_step == fepriv->started_auto_step) &&
|
|
|
|
(fepriv->auto_sub_step == 0) && check_wrapped) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: drift:%i inversion:%i auto_step:%i " \
|
|
|
|
"auto_sub_step:%i started_auto_step:%i\n",
|
|
|
|
__func__, fepriv->lnb_drift, fepriv->inversion,
|
|
|
|
fepriv->auto_step, fepriv->auto_sub_step,
|
|
|
|
fepriv->started_auto_step);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* set the frontend itself */
|
2011-12-30 20:30:25 +08:00
|
|
|
c->frequency += fepriv->lnb_drift;
|
2005-04-17 06:20:36 +08:00
|
|
|
if (autoinversion)
|
2011-12-30 20:30:25 +08:00
|
|
|
c->inversion = fepriv->inversion;
|
|
|
|
tmp = *c;
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.set_frontend)
|
2011-12-21 02:31:54 +08:00
|
|
|
fe_set_err = fe->ops.set_frontend(fe);
|
2011-12-30 20:30:25 +08:00
|
|
|
*c = tmp;
|
2009-09-02 06:23:09 +08:00
|
|
|
if (fe_set_err < 0) {
|
|
|
|
fepriv->state = FESTATE_ERROR;
|
|
|
|
return fe_set_err;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-12-30 20:30:25 +08:00
|
|
|
c->frequency = original_frequency;
|
|
|
|
c->inversion = original_inversion;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
fepriv->auto_sub_step++;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-01-10 01:25:07 +08:00
|
|
|
static void dvb_frontend_swzigzag(struct dvb_frontend *fe)
|
|
|
|
{
|
2015-06-08 01:53:52 +08:00
|
|
|
enum fe_status s = 0;
|
2009-09-02 06:23:09 +08:00
|
|
|
int retval = 0;
|
2006-01-10 01:25:07 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2011-12-30 20:30:25 +08:00
|
|
|
struct dtv_frontend_properties *c = &fe->dtv_property_cache, tmp;
|
2006-01-10 01:25:07 +08:00
|
|
|
|
|
|
|
/* if we've got no parameters, just keep idling */
|
|
|
|
if (fepriv->state & FESTATE_IDLE) {
|
|
|
|
fepriv->delay = 3*HZ;
|
|
|
|
fepriv->quality = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* in SCAN mode, we just set the frontend when asked and leave it alone */
|
|
|
|
if (fepriv->tune_mode_flags & FE_TUNE_MODE_ONESHOT) {
|
|
|
|
if (fepriv->state & FESTATE_RETUNE) {
|
2011-12-30 20:30:25 +08:00
|
|
|
tmp = *c;
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.set_frontend)
|
2011-12-21 02:31:54 +08:00
|
|
|
retval = fe->ops.set_frontend(fe);
|
2011-12-30 20:30:25 +08:00
|
|
|
*c = tmp;
|
2009-09-02 06:23:09 +08:00
|
|
|
if (retval < 0)
|
|
|
|
fepriv->state = FESTATE_ERROR;
|
|
|
|
else
|
|
|
|
fepriv->state = FESTATE_TUNED;
|
2006-01-10 01:25:07 +08:00
|
|
|
}
|
|
|
|
fepriv->delay = 3*HZ;
|
|
|
|
fepriv->quality = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* get the frontend status */
|
|
|
|
if (fepriv->state & FESTATE_RETUNE) {
|
|
|
|
s = 0;
|
|
|
|
} else {
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.read_status)
|
|
|
|
fe->ops.read_status(fe, &s);
|
2006-01-10 01:25:07 +08:00
|
|
|
if (s != fepriv->status) {
|
|
|
|
dvb_frontend_add_event(fe, s);
|
|
|
|
fepriv->status = s;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* if we're not tuned, and we have a lock, move to the TUNED state */
|
|
|
|
if ((fepriv->state & FESTATE_WAITFORLOCK) && (s & FE_HAS_LOCK)) {
|
|
|
|
dvb_frontend_swzigzag_update_delay(fepriv, s & FE_HAS_LOCK);
|
|
|
|
fepriv->state = FESTATE_TUNED;
|
|
|
|
|
|
|
|
/* if we're tuned, then we have determined the correct inversion */
|
2006-05-14 16:01:31 +08:00
|
|
|
if ((!(fe->ops.info.caps & FE_CAN_INVERSION_AUTO)) &&
|
2011-12-30 20:30:25 +08:00
|
|
|
(c->inversion == INVERSION_AUTO)) {
|
|
|
|
c->inversion = fepriv->inversion;
|
2006-01-10 01:25:07 +08:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* if we are tuned already, check we're still locked */
|
|
|
|
if (fepriv->state & FESTATE_TUNED) {
|
|
|
|
dvb_frontend_swzigzag_update_delay(fepriv, s & FE_HAS_LOCK);
|
|
|
|
|
|
|
|
/* we're tuned, and the lock is still good... */
|
|
|
|
if (s & FE_HAS_LOCK) {
|
|
|
|
return;
|
|
|
|
} else { /* if we _WERE_ tuned, but now don't have a lock */
|
|
|
|
fepriv->state = FESTATE_ZIGZAG_FAST;
|
|
|
|
fepriv->started_auto_step = fepriv->auto_step;
|
|
|
|
fepriv->check_wrapped = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* don't actually do anything if we're in the LOSTLOCK state,
|
|
|
|
* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0 */
|
|
|
|
if ((fepriv->state & FESTATE_LOSTLOCK) &&
|
2006-05-14 16:01:31 +08:00
|
|
|
(fe->ops.info.caps & FE_CAN_RECOVER) && (fepriv->max_drift == 0)) {
|
2006-01-10 01:25:07 +08:00
|
|
|
dvb_frontend_swzigzag_update_delay(fepriv, s & FE_HAS_LOCK);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* don't do anything if we're in the DISEQC state, since this
|
|
|
|
* might be someone with a motorized dish controlled by DISEQC.
|
|
|
|
* If its actually a re-tune, there will be a SET_FRONTEND soon enough. */
|
|
|
|
if (fepriv->state & FESTATE_DISEQC) {
|
|
|
|
dvb_frontend_swzigzag_update_delay(fepriv, s & FE_HAS_LOCK);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* if we're in the RETUNE state, set everything up for a brand
|
|
|
|
* new scan, keeping the current inversion setting, as the next
|
|
|
|
* tune is _very_ likely to require the same */
|
|
|
|
if (fepriv->state & FESTATE_RETUNE) {
|
|
|
|
fepriv->lnb_drift = 0;
|
|
|
|
fepriv->auto_step = 0;
|
|
|
|
fepriv->auto_sub_step = 0;
|
|
|
|
fepriv->started_auto_step = 0;
|
|
|
|
fepriv->check_wrapped = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* fast zigzag. */
|
|
|
|
if ((fepriv->state & FESTATE_SEARCHING_FAST) || (fepriv->state & FESTATE_RETUNE)) {
|
|
|
|
fepriv->delay = fepriv->min_delay;
|
|
|
|
|
2010-05-06 20:30:25 +08:00
|
|
|
/* perform a tune */
|
2009-09-02 06:23:09 +08:00
|
|
|
retval = dvb_frontend_swzigzag_autotune(fe,
|
|
|
|
fepriv->check_wrapped);
|
|
|
|
if (retval < 0) {
|
|
|
|
return;
|
|
|
|
} else if (retval) {
|
2006-01-10 01:25:07 +08:00
|
|
|
/* OK, if we've run out of trials at the fast speed.
|
|
|
|
* Drop back to slow for the _next_ attempt */
|
|
|
|
fepriv->state = FESTATE_SEARCHING_SLOW;
|
|
|
|
fepriv->started_auto_step = fepriv->auto_step;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
fepriv->check_wrapped = 1;
|
|
|
|
|
|
|
|
/* if we've just retuned, enter the ZIGZAG_FAST state.
|
|
|
|
* This ensures we cannot return from an
|
|
|
|
* FE_SET_FRONTEND ioctl before the first frontend tune
|
|
|
|
* occurs */
|
|
|
|
if (fepriv->state & FESTATE_RETUNE) {
|
|
|
|
fepriv->state = FESTATE_TUNING_FAST;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* slow zigzag */
|
|
|
|
if (fepriv->state & FESTATE_SEARCHING_SLOW) {
|
|
|
|
dvb_frontend_swzigzag_update_delay(fepriv, s & FE_HAS_LOCK);
|
|
|
|
|
|
|
|
/* Note: don't bother checking for wrapping; we stay in this
|
|
|
|
* state until we get a lock */
|
|
|
|
dvb_frontend_swzigzag_autotune(fe, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static int dvb_frontend_is_exiting(struct dvb_frontend *fe)
|
|
|
|
{
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-07-13 00:44:12 +08:00
|
|
|
if (fe->exit != DVB_FE_NO_EXIT)
|
2005-04-17 06:20:36 +08:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
if (fepriv->dvbdev->writers == 1)
|
2011-12-10 08:37:00 +08:00
|
|
|
if (time_after_eq(jiffies, fepriv->release_jiffies +
|
2006-01-10 01:25:07 +08:00
|
|
|
dvb_shutdown_timeout * HZ))
|
2005-04-17 06:20:36 +08:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dvb_frontend_should_wakeup(struct dvb_frontend *fe)
|
|
|
|
{
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (fepriv->wakeup) {
|
|
|
|
fepriv->wakeup = 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return dvb_frontend_is_exiting(fe);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dvb_frontend_wakeup(struct dvb_frontend *fe)
|
|
|
|
{
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
fepriv->wakeup = 1;
|
|
|
|
wake_up_interruptible(&fepriv->wait_queue);
|
|
|
|
}
|
|
|
|
|
2015-01-07 00:57:55 +08:00
|
|
|
/**
|
|
|
|
* dvb_enable_media_tuner() - tries to enable the DVB tuner
|
|
|
|
*
|
|
|
|
* @fe: struct dvb_frontend pointer
|
|
|
|
*
|
|
|
|
* This function ensures that just one media tuner is enabled for a given
|
|
|
|
* frontend. It has two different behaviors:
|
|
|
|
* - For trivial devices with just one tuner:
|
|
|
|
* it just enables the existing tuner->fe link
|
|
|
|
* - For devices with more than one tuner:
|
|
|
|
* It is up to the driver to implement the logic that will enable one tuner
|
|
|
|
* and disable the other ones. However, if more than one tuner is enabled for
|
|
|
|
* the same frontend, it will print an error message and return -EINVAL.
|
|
|
|
*
|
|
|
|
* At return, it will return the error code returned by media_entity_setup_link,
|
|
|
|
* or 0 if everything is OK, if no tuner is linked to the frontend or if the
|
|
|
|
* mdev is NULL.
|
|
|
|
*/
|
2015-01-07 04:53:15 +08:00
|
|
|
#ifdef CONFIG_MEDIA_CONTROLLER_DVB
|
2015-01-07 00:57:55 +08:00
|
|
|
static int dvb_enable_media_tuner(struct dvb_frontend *fe)
|
|
|
|
{
|
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
|
|
|
struct dvb_adapter *adapter = fe->dvb;
|
|
|
|
struct media_device *mdev = adapter->mdev;
|
|
|
|
struct media_entity *entity, *source;
|
|
|
|
struct media_link *link, *found_link = NULL;
|
[media] media: convert links from array to list
The entire logic that represent graph links were developed on a
time where there were no needs to dynamic remove links. So,
although links are created/removed one by one via some
functions, they're stored as an array inside the entity struct.
As the array may grow, there's a logic inside the code that
checks if the amount of space is not enough to store
the needed links. If it isn't the core uses krealloc()
to change the size of the link, with is bad, as it
leaves the memory fragmented.
So, convert links into a list.
Also, currently, both source and sink entities need the link
at the graph traversal logic inside media_entity. So there's
a logic duplicating all links. That makes it to spend
twice the memory needed. This is not a big deal for today's
usage, where the number of links are not big.
Yet, if during the MC workshop discussions, it was said that
IIO graphs could have up to 4,000 entities. So, we may
want to remove the duplication on some future. The problem
is that it would require a separate linked list to store
the backlinks inside the entity, or to use a more complex
algorithm to do graph backlink traversal, with is something
that the current graph traversal inside the core can't cope
with. So, let's postpone a such change if/when it is actually
needed.
It should also be noticed that the media_link structure uses
44 bytes on 32-bit architectures and 84 bytes on 64-bit
architecture. It will thus be allocated out of the 64-bytes and
96-bytes pools respectively. That's a 12.5% memory waste on
64-bit architectures and 31.25% on 32-bit architecture.
A linked list is less efficient than an array in this case, but
this could later be optimized if we can get rid of the reverse
links (with would reduce memory allocation by 50%).
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-08-07 17:55:40 +08:00
|
|
|
int ret, n_links = 0, active_links = 0;
|
2015-01-07 00:57:55 +08:00
|
|
|
|
2015-01-07 04:53:15 +08:00
|
|
|
fepriv->pipe_start_entity = NULL;
|
|
|
|
|
2015-01-07 00:57:55 +08:00
|
|
|
if (!mdev)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
entity = fepriv->dvbdev->entity;
|
2015-01-07 04:53:15 +08:00
|
|
|
fepriv->pipe_start_entity = entity;
|
|
|
|
|
[media] media: convert links from array to list
The entire logic that represent graph links were developed on a
time where there were no needs to dynamic remove links. So,
although links are created/removed one by one via some
functions, they're stored as an array inside the entity struct.
As the array may grow, there's a logic inside the code that
checks if the amount of space is not enough to store
the needed links. If it isn't the core uses krealloc()
to change the size of the link, with is bad, as it
leaves the memory fragmented.
So, convert links into a list.
Also, currently, both source and sink entities need the link
at the graph traversal logic inside media_entity. So there's
a logic duplicating all links. That makes it to spend
twice the memory needed. This is not a big deal for today's
usage, where the number of links are not big.
Yet, if during the MC workshop discussions, it was said that
IIO graphs could have up to 4,000 entities. So, we may
want to remove the duplication on some future. The problem
is that it would require a separate linked list to store
the backlinks inside the entity, or to use a more complex
algorithm to do graph backlink traversal, with is something
that the current graph traversal inside the core can't cope
with. So, let's postpone a such change if/when it is actually
needed.
It should also be noticed that the media_link structure uses
44 bytes on 32-bit architectures and 84 bytes on 64-bit
architecture. It will thus be allocated out of the 64-bytes and
96-bytes pools respectively. That's a 12.5% memory waste on
64-bit architectures and 31.25% on 32-bit architecture.
A linked list is less efficient than an array in this case, but
this could later be optimized if we can get rid of the reverse
links (with would reduce memory allocation by 50%).
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-08-07 17:55:40 +08:00
|
|
|
list_for_each_entry(link, &entity->links, list) {
|
2015-01-07 00:57:55 +08:00
|
|
|
if (link->sink->entity == entity) {
|
|
|
|
found_link = link;
|
|
|
|
n_links++;
|
|
|
|
if (link->flags & MEDIA_LNK_FL_ENABLED)
|
|
|
|
active_links++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!n_links || active_links == 1 || !found_link)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If a frontend has more than one tuner linked, it is up to the driver
|
|
|
|
* to select with one will be the active one, as the frontend core can't
|
|
|
|
* guess. If the driver doesn't do that, it is a bug.
|
|
|
|
*/
|
|
|
|
if (n_links > 1 && active_links != 1) {
|
|
|
|
dev_err(fe->dvb->device,
|
|
|
|
"WARNING: there are %d active links among %d tuners. This is a driver's bug!\n",
|
|
|
|
active_links, n_links);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
source = found_link->source->entity;
|
2015-01-07 04:53:15 +08:00
|
|
|
fepriv->pipe_start_entity = source;
|
[media] media: convert links from array to list
The entire logic that represent graph links were developed on a
time where there were no needs to dynamic remove links. So,
although links are created/removed one by one via some
functions, they're stored as an array inside the entity struct.
As the array may grow, there's a logic inside the code that
checks if the amount of space is not enough to store
the needed links. If it isn't the core uses krealloc()
to change the size of the link, with is bad, as it
leaves the memory fragmented.
So, convert links into a list.
Also, currently, both source and sink entities need the link
at the graph traversal logic inside media_entity. So there's
a logic duplicating all links. That makes it to spend
twice the memory needed. This is not a big deal for today's
usage, where the number of links are not big.
Yet, if during the MC workshop discussions, it was said that
IIO graphs could have up to 4,000 entities. So, we may
want to remove the duplication on some future. The problem
is that it would require a separate linked list to store
the backlinks inside the entity, or to use a more complex
algorithm to do graph backlink traversal, with is something
that the current graph traversal inside the core can't cope
with. So, let's postpone a such change if/when it is actually
needed.
It should also be noticed that the media_link structure uses
44 bytes on 32-bit architectures and 84 bytes on 64-bit
architecture. It will thus be allocated out of the 64-bytes and
96-bytes pools respectively. That's a 12.5% memory waste on
64-bit architectures and 31.25% on 32-bit architecture.
A linked list is less efficient than an array in this case, but
this could later be optimized if we can get rid of the reverse
links (with would reduce memory allocation by 50%).
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-08-07 17:55:40 +08:00
|
|
|
list_for_each_entry(link, &source->links, list) {
|
2015-01-07 00:57:55 +08:00
|
|
|
struct media_entity *sink;
|
|
|
|
int flags = 0;
|
|
|
|
|
|
|
|
sink = link->sink->entity;
|
|
|
|
if (sink == entity)
|
|
|
|
flags = MEDIA_LNK_FL_ENABLED;
|
|
|
|
|
|
|
|
ret = media_entity_setup_link(link, flags);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(fe->dvb->device,
|
|
|
|
"Couldn't change link %s->%s to %s. Error %d\n",
|
|
|
|
source->name, sink->name,
|
|
|
|
flags ? "enabled" : "disabled",
|
|
|
|
ret);
|
|
|
|
return ret;
|
|
|
|
} else
|
|
|
|
dev_dbg(fe->dvb->device,
|
|
|
|
"link %s->%s was %s\n",
|
|
|
|
source->name, sink->name,
|
|
|
|
flags ? "ENABLED" : "disabled");
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2015-01-07 04:53:15 +08:00
|
|
|
#endif
|
2015-01-07 00:57:55 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static int dvb_frontend_thread(void *data)
|
|
|
|
{
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend *fe = data;
|
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2015-06-08 01:53:52 +08:00
|
|
|
enum fe_status s;
|
2008-10-15 03:34:07 +08:00
|
|
|
enum dvbfe_algo algo;
|
2015-02-18 22:43:44 +08:00
|
|
|
#ifdef CONFIG_MEDIA_CONTROLLER_DVB
|
2015-01-07 00:57:55 +08:00
|
|
|
int ret;
|
2015-02-18 22:43:44 +08:00
|
|
|
#endif
|
2008-10-15 03:34:07 +08:00
|
|
|
|
2011-12-27 04:48:33 +08:00
|
|
|
bool re_tune = false;
|
2012-12-24 04:23:06 +08:00
|
|
|
bool semheld = false;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s:\n", __func__);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-01-10 01:25:07 +08:00
|
|
|
fepriv->check_wrapped = 0;
|
|
|
|
fepriv->quality = 0;
|
|
|
|
fepriv->delay = 3*HZ;
|
2005-04-17 06:20:36 +08:00
|
|
|
fepriv->status = 0;
|
|
|
|
fepriv->wakeup = 0;
|
2006-07-10 14:34:14 +08:00
|
|
|
fepriv->reinitialise = 0;
|
|
|
|
|
2015-01-07 04:53:15 +08:00
|
|
|
#ifdef CONFIG_MEDIA_CONTROLLER_DVB
|
2015-01-07 00:57:55 +08:00
|
|
|
ret = dvb_enable_media_tuner(fe);
|
|
|
|
if (ret) {
|
|
|
|
/* FIXME: return an error if it fails */
|
|
|
|
dev_info(fe->dvb->device,
|
|
|
|
"proceeding with FE task\n");
|
2015-02-23 20:41:17 +08:00
|
|
|
} else if (fepriv->pipe_start_entity) {
|
2015-01-07 04:53:15 +08:00
|
|
|
ret = media_entity_pipeline_start(fepriv->pipe_start_entity,
|
|
|
|
&fepriv->pipe);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2015-01-07 00:57:55 +08:00
|
|
|
}
|
2015-01-07 04:53:15 +08:00
|
|
|
#endif
|
2015-01-07 00:57:55 +08:00
|
|
|
|
2006-07-10 14:34:14 +08:00
|
|
|
dvb_frontend_init(fe);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-07-17 19:03:35 +08:00
|
|
|
set_freezable();
|
2005-04-17 06:20:36 +08:00
|
|
|
while (1) {
|
|
|
|
up(&fepriv->sem); /* is locked when we enter the thread... */
|
2007-02-09 01:36:57 +08:00
|
|
|
restart:
|
2011-08-27 22:30:25 +08:00
|
|
|
wait_event_interruptible_timeout(fepriv->wait_queue,
|
2007-10-18 18:04:45 +08:00
|
|
|
dvb_frontend_should_wakeup(fe) || kthread_should_stop()
|
|
|
|
|| freezing(current),
|
2007-02-09 01:32:43 +08:00
|
|
|
fepriv->delay);
|
|
|
|
|
|
|
|
if (kthread_should_stop() || dvb_frontend_is_exiting(fe)) {
|
2005-04-17 06:20:36 +08:00
|
|
|
/* got signal or quitting */
|
2012-12-24 04:23:06 +08:00
|
|
|
if (!down_interruptible(&fepriv->sem))
|
|
|
|
semheld = true;
|
2014-07-13 00:44:12 +08:00
|
|
|
fe->exit = DVB_FE_NORMAL_EXIT;
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2007-02-09 01:32:43 +08:00
|
|
|
if (try_to_freeze())
|
2007-02-09 01:36:57 +08:00
|
|
|
goto restart;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (down_interruptible(&fepriv->sem))
|
|
|
|
break;
|
|
|
|
|
2006-03-31 02:53:35 +08:00
|
|
|
if (fepriv->reinitialise) {
|
|
|
|
dvb_frontend_init(fe);
|
2011-08-25 01:33:52 +08:00
|
|
|
if (fe->ops.set_tone && fepriv->tone != -1)
|
2006-05-14 16:01:31 +08:00
|
|
|
fe->ops.set_tone(fe, fepriv->tone);
|
2011-08-25 01:33:52 +08:00
|
|
|
if (fe->ops.set_voltage && fepriv->voltage != -1)
|
2006-05-14 16:01:31 +08:00
|
|
|
fe->ops.set_voltage(fe, fepriv->voltage);
|
2006-03-31 02:53:35 +08:00
|
|
|
fepriv->reinitialise = 0;
|
|
|
|
}
|
|
|
|
|
2006-01-10 01:25:07 +08:00
|
|
|
/* do an iteration of the tuning loop */
|
2006-06-24 22:18:58 +08:00
|
|
|
if (fe->ops.get_frontend_algo) {
|
2008-10-15 03:34:07 +08:00
|
|
|
algo = fe->ops.get_frontend_algo(fe);
|
|
|
|
switch (algo) {
|
|
|
|
case DVBFE_ALGO_HW:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Frontend ALGO = DVBFE_ALGO_HW\n", __func__);
|
2008-10-15 03:34:07 +08:00
|
|
|
|
2006-06-24 22:18:58 +08:00
|
|
|
if (fepriv->state & FESTATE_RETUNE) {
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Retune requested, FESTATE_RETUNE\n", __func__);
|
2011-12-27 04:48:33 +08:00
|
|
|
re_tune = true;
|
2006-06-24 22:18:58 +08:00
|
|
|
fepriv->state = FESTATE_TUNED;
|
[media] dvb-core: fix DVBFE_ALGO_HW retune bug
Commit 7e07222 breaks DVBFE_ALGO_HW tuning after a retune is requested,
which causes bad tuning on my TBS 6920.
[ 0.769091] pci 0000:06:00.0: [14f1:8852] type 0 class 0x000400
[ 19.733530] CORE cx23885[0]: subsystem: 6920:8888, board: TurboSight TBS 6920 [card=14,autodetected]
[ 762.824912] cx24116_load_firmware: FW version 1.23.86.1
7e0722215a510921cbb73ab4c37477d4dcb91bf8 [media] dvb-core: Don't pass DVBv3 parameters on tune() fops
Although re_tune is set to true when FESTATE_RETUNE occurs, it is never
set back to false which the old code used to do when !FESTATE_RETUNE.
This patch sets re_tune to false if !(state & FESTATE_RETUNE).
$ szap-s2 -a 2 "Channel 5"
reading channels from file '/home/simon/.szap/channels.conf'
zapping to 247 'Channel 5':
delivery DVB-S, modulation QPSK
sat 0, frequency 10964 MHz H, symbolrate 22000000, coderate 5/6, rolloff 0.35
vpid 0x092a, apid 0x092b, sid 0x092d
using '/dev/dvb/adapter2/frontend0' and '/dev/dvb/adapter2/demux0'
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eb33 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cec0 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cec0 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-02-07 04:57:01 +08:00
|
|
|
} else {
|
|
|
|
re_tune = false;
|
2006-06-24 22:18:58 +08:00
|
|
|
}
|
|
|
|
|
2008-10-15 03:34:07 +08:00
|
|
|
if (fe->ops.tune)
|
2011-12-27 04:48:33 +08:00
|
|
|
fe->ops.tune(fe, re_tune, fepriv->tune_mode_flags, &fepriv->delay, &s);
|
2008-10-15 03:34:07 +08:00
|
|
|
|
2008-12-18 17:27:50 +08:00
|
|
|
if (s != fepriv->status && !(fepriv->tune_mode_flags & FE_TUNE_MODE_ONESHOT)) {
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: state changed, adding current state\n", __func__);
|
2006-06-24 22:18:58 +08:00
|
|
|
dvb_frontend_add_event(fe, s);
|
|
|
|
fepriv->status = s;
|
|
|
|
}
|
2008-10-15 03:34:07 +08:00
|
|
|
break;
|
|
|
|
case DVBFE_ALGO_SW:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Frontend ALGO = DVBFE_ALGO_SW\n", __func__);
|
2006-06-30 09:05:23 +08:00
|
|
|
dvb_frontend_swzigzag(fe);
|
2008-10-15 03:34:07 +08:00
|
|
|
break;
|
|
|
|
case DVBFE_ALGO_CUSTOM:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Frontend ALGO = DVBFE_ALGO_CUSTOM, state=%d\n", __func__, fepriv->state);
|
2008-10-15 03:34:07 +08:00
|
|
|
if (fepriv->state & FESTATE_RETUNE) {
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Retune requested, FESTAT_RETUNE\n", __func__);
|
2008-10-15 03:34:07 +08:00
|
|
|
fepriv->state = FESTATE_TUNED;
|
|
|
|
}
|
|
|
|
/* Case where we are going to search for a carrier
|
|
|
|
* User asked us to retune again for some reason, possibly
|
|
|
|
* requesting a search with a new set of parameters
|
|
|
|
*/
|
|
|
|
if (fepriv->algo_status & DVBFE_ALGO_SEARCH_AGAIN) {
|
2008-10-20 17:05:21 +08:00
|
|
|
if (fe->ops.search) {
|
2011-12-27 05:03:12 +08:00
|
|
|
fepriv->algo_status = fe->ops.search(fe);
|
2008-10-15 03:34:07 +08:00
|
|
|
/* We did do a search as was requested, the flags are
|
|
|
|
* now unset as well and has the flags wrt to search.
|
|
|
|
*/
|
2008-10-20 17:05:21 +08:00
|
|
|
} else {
|
|
|
|
fepriv->algo_status &= ~DVBFE_ALGO_SEARCH_AGAIN;
|
|
|
|
}
|
2008-10-15 03:34:07 +08:00
|
|
|
}
|
|
|
|
/* Track the carrier if the search was successful */
|
2011-12-27 05:11:25 +08:00
|
|
|
if (fepriv->algo_status != DVBFE_ALGO_SEARCH_SUCCESS) {
|
2008-10-20 17:05:21 +08:00
|
|
|
fepriv->algo_status |= DVBFE_ALGO_SEARCH_AGAIN;
|
|
|
|
fepriv->delay = HZ / 2;
|
|
|
|
}
|
2012-04-07 05:38:18 +08:00
|
|
|
dtv_property_legacy_params_sync(fe, &fepriv->parameters_out);
|
2008-10-20 17:05:21 +08:00
|
|
|
fe->ops.read_status(fe, &s);
|
|
|
|
if (s != fepriv->status) {
|
|
|
|
dvb_frontend_add_event(fe, s); /* update event list */
|
|
|
|
fepriv->status = s;
|
|
|
|
if (!(s & FE_HAS_LOCK)) {
|
|
|
|
fepriv->delay = HZ / 10;
|
|
|
|
fepriv->algo_status |= DVBFE_ALGO_SEARCH_AGAIN;
|
|
|
|
} else {
|
|
|
|
fepriv->delay = 60 * HZ;
|
|
|
|
}
|
2008-10-15 03:34:07 +08:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: UNDEFINED ALGO !\n", __func__);
|
2008-10-15 03:34:07 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
} else {
|
2006-06-25 16:46:26 +08:00
|
|
|
dvb_frontend_swzigzag(fe);
|
2008-10-15 03:34:07 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2015-01-07 04:53:15 +08:00
|
|
|
#ifdef CONFIG_MEDIA_CONTROLLER_DVB
|
2015-02-23 20:41:17 +08:00
|
|
|
if (fepriv->pipe_start_entity)
|
|
|
|
media_entity_pipeline_stop(fepriv->pipe_start_entity);
|
2015-01-07 04:53:15 +08:00
|
|
|
fepriv->pipe_start_entity = NULL;
|
|
|
|
#endif
|
|
|
|
|
2007-08-26 00:17:53 +08:00
|
|
|
if (dvb_powerdown_on_sleep) {
|
|
|
|
if (fe->ops.set_voltage)
|
|
|
|
fe->ops.set_voltage(fe, SEC_VOLTAGE_OFF);
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.tuner_ops.sleep) {
|
2008-11-16 11:44:52 +08:00
|
|
|
if (fe->ops.i2c_gate_ctrl)
|
|
|
|
fe->ops.i2c_gate_ctrl(fe, 1);
|
2006-05-14 16:01:31 +08:00
|
|
|
fe->ops.tuner_ops.sleep(fe);
|
|
|
|
if (fe->ops.i2c_gate_ctrl)
|
|
|
|
fe->ops.i2c_gate_ctrl(fe, 0);
|
2006-04-19 04:47:09 +08:00
|
|
|
}
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.sleep)
|
|
|
|
fe->ops.sleep(fe);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2007-02-09 01:32:43 +08:00
|
|
|
fepriv->thread = NULL;
|
2010-05-06 02:59:20 +08:00
|
|
|
if (kthread_should_stop())
|
2014-07-13 00:44:12 +08:00
|
|
|
fe->exit = DVB_FE_DEVICE_REMOVED;
|
2010-05-06 02:59:20 +08:00
|
|
|
else
|
2014-07-13 00:44:12 +08:00
|
|
|
fe->exit = DVB_FE_NO_EXIT;
|
2005-04-17 06:20:36 +08:00
|
|
|
mb();
|
|
|
|
|
2012-12-24 04:23:06 +08:00
|
|
|
if (semheld)
|
|
|
|
up(&fepriv->sem);
|
2005-04-17 06:20:36 +08:00
|
|
|
dvb_frontend_wakeup(fe);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dvb_frontend_stop(struct dvb_frontend *fe)
|
|
|
|
{
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s:\n", __func__);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-07-13 00:44:12 +08:00
|
|
|
if (fe->exit != DVB_FE_DEVICE_REMOVED)
|
|
|
|
fe->exit = DVB_FE_NORMAL_EXIT;
|
2005-04-17 06:20:36 +08:00
|
|
|
mb();
|
|
|
|
|
2007-02-09 01:32:43 +08:00
|
|
|
if (!fepriv->thread)
|
2005-04-17 06:20:36 +08:00
|
|
|
return;
|
|
|
|
|
2007-02-09 01:32:43 +08:00
|
|
|
kthread_stop(fepriv->thread);
|
2007-04-14 21:18:58 +08:00
|
|
|
|
2010-09-07 22:33:27 +08:00
|
|
|
sema_init(&fepriv->sem, 1);
|
2005-04-17 06:20:36 +08:00
|
|
|
fepriv->state = FESTATE_IDLE;
|
|
|
|
|
|
|
|
/* paranoia check in case a signal arrived */
|
2007-02-09 01:32:43 +08:00
|
|
|
if (fepriv->thread)
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_warn(fe->dvb->device,
|
|
|
|
"dvb_frontend_stop: warning: thread %p won't exit\n",
|
2007-02-09 01:32:43 +08:00
|
|
|
fepriv->thread);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2005-11-09 13:35:27 +08:00
|
|
|
/*
|
2015-11-10 09:24:10 +08:00
|
|
|
* Sleep for the amount of time given by add_usec parameter
|
|
|
|
*
|
|
|
|
* This needs to be as precise as possible, as it affects the detection of
|
|
|
|
* the dish tone command at the satellite subsystem. The precision is improved
|
|
|
|
* by using a scheduled msleep followed by udelay for the remainder.
|
2005-11-09 13:35:27 +08:00
|
|
|
*/
|
2015-05-31 15:17:06 +08:00
|
|
|
void dvb_frontend_sleep_until(ktime_t *waketime, u32 add_usec)
|
2005-11-09 13:35:27 +08:00
|
|
|
{
|
2015-11-18 22:55:47 +08:00
|
|
|
s32 delta;
|
2005-11-09 13:35:27 +08:00
|
|
|
|
2015-11-18 22:55:47 +08:00
|
|
|
*waketime = ktime_add_us(*waketime, add_usec);
|
2015-05-31 15:17:06 +08:00
|
|
|
delta = ktime_us_delta(ktime_get_real(), *waketime);
|
2005-11-09 13:35:27 +08:00
|
|
|
if (delta > 2500) {
|
|
|
|
msleep((delta - 1500) / 1000);
|
2015-11-18 22:55:47 +08:00
|
|
|
delta = ktime_us_delta(ktime_get_real(), *waketime);
|
2005-11-09 13:35:27 +08:00
|
|
|
}
|
|
|
|
if (delta > 0)
|
|
|
|
udelay(delta);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dvb_frontend_sleep_until);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static int dvb_frontend_start(struct dvb_frontend *fe)
|
|
|
|
{
|
|
|
|
int ret;
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2007-02-09 01:32:43 +08:00
|
|
|
struct task_struct *fe_thread;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s:\n", __func__);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-02-09 01:32:43 +08:00
|
|
|
if (fepriv->thread) {
|
2014-07-13 00:44:12 +08:00
|
|
|
if (fe->exit == DVB_FE_NO_EXIT)
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
else
|
|
|
|
dvb_frontend_stop (fe);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (signal_pending(current))
|
|
|
|
return -EINTR;
|
|
|
|
if (down_interruptible (&fepriv->sem))
|
|
|
|
return -EINTR;
|
|
|
|
|
|
|
|
fepriv->state = FESTATE_IDLE;
|
2014-07-13 00:44:12 +08:00
|
|
|
fe->exit = DVB_FE_NO_EXIT;
|
2007-02-09 01:32:43 +08:00
|
|
|
fepriv->thread = NULL;
|
2005-04-17 06:20:36 +08:00
|
|
|
mb();
|
|
|
|
|
2007-02-09 01:32:43 +08:00
|
|
|
fe_thread = kthread_run(dvb_frontend_thread, fe,
|
2008-10-11 22:05:50 +08:00
|
|
|
"kdvb-ad-%i-fe-%i", fe->dvb->num,fe->id);
|
2007-02-09 01:32:43 +08:00
|
|
|
if (IS_ERR(fe_thread)) {
|
|
|
|
ret = PTR_ERR(fe_thread);
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_warn(fe->dvb->device,
|
|
|
|
"dvb_frontend_start: failed to start kthread (%d)\n",
|
|
|
|
ret);
|
2005-04-17 06:20:36 +08:00
|
|
|
up(&fepriv->sem);
|
|
|
|
return ret;
|
|
|
|
}
|
2007-02-09 01:32:43 +08:00
|
|
|
fepriv->thread = fe_thread;
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-05-06 20:30:25 +08:00
|
|
|
static void dvb_frontend_get_frequency_limits(struct dvb_frontend *fe,
|
2007-08-09 12:03:42 +08:00
|
|
|
u32 *freq_min, u32 *freq_max)
|
|
|
|
{
|
|
|
|
*freq_min = max(fe->ops.info.frequency_min, fe->ops.tuner_ops.info.frequency_min);
|
|
|
|
|
|
|
|
if (fe->ops.info.frequency_max == 0)
|
|
|
|
*freq_max = fe->ops.tuner_ops.info.frequency_max;
|
|
|
|
else if (fe->ops.tuner_ops.info.frequency_max == 0)
|
|
|
|
*freq_max = fe->ops.info.frequency_max;
|
|
|
|
else
|
|
|
|
*freq_max = min(fe->ops.info.frequency_max, fe->ops.tuner_ops.info.frequency_max);
|
|
|
|
|
|
|
|
if (*freq_min == 0 || *freq_max == 0)
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_warn(fe->dvb->device, "DVB: adapter %i frontend %u frequency limits undefined - fix the driver\n",
|
|
|
|
fe->dvb->num, fe->id);
|
2007-08-09 12:03:42 +08:00
|
|
|
}
|
|
|
|
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
static int dvb_frontend_check_parameters(struct dvb_frontend *fe)
|
2007-07-24 08:00:36 +08:00
|
|
|
{
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
|
2007-08-09 12:03:42 +08:00
|
|
|
u32 freq_min;
|
|
|
|
u32 freq_max;
|
|
|
|
|
2007-07-24 08:00:36 +08:00
|
|
|
/* range check: frequency */
|
2010-05-06 20:30:25 +08:00
|
|
|
dvb_frontend_get_frequency_limits(fe, &freq_min, &freq_max);
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
if ((freq_min && c->frequency < freq_min) ||
|
|
|
|
(freq_max && c->frequency > freq_max)) {
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_warn(fe->dvb->device, "DVB: adapter %i frontend %i frequency %u out of range (%u..%u)\n",
|
|
|
|
fe->dvb->num, fe->id, c->frequency,
|
|
|
|
freq_min, freq_max);
|
2007-07-24 08:00:36 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* range check: symbol rate */
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
switch (c->delivery_system) {
|
|
|
|
case SYS_DVBS:
|
|
|
|
case SYS_DVBS2:
|
|
|
|
case SYS_TURBO:
|
|
|
|
case SYS_DVBC_ANNEX_A:
|
|
|
|
case SYS_DVBC_ANNEX_C:
|
2007-07-24 08:00:36 +08:00
|
|
|
if ((fe->ops.info.symbol_rate_min &&
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
c->symbol_rate < fe->ops.info.symbol_rate_min) ||
|
2007-07-24 08:00:36 +08:00
|
|
|
(fe->ops.info.symbol_rate_max &&
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
c->symbol_rate > fe->ops.info.symbol_rate_max)) {
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_warn(fe->dvb->device, "DVB: adapter %i frontend %i symbol rate %u out of range (%u..%u)\n",
|
|
|
|
fe->dvb->num, fe->id, c->symbol_rate,
|
|
|
|
fe->ops.info.symbol_rate_min,
|
|
|
|
fe->ops.info.symbol_rate_max);
|
2007-07-24 08:00:36 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
default:
|
|
|
|
break;
|
2007-07-24 08:00:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-08-04 01:39:15 +08:00
|
|
|
static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
|
|
|
|
{
|
2011-05-09 07:03:39 +08:00
|
|
|
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
|
2009-08-04 01:39:15 +08:00
|
|
|
int i;
|
2012-01-13 21:46:36 +08:00
|
|
|
u32 delsys;
|
2009-08-04 01:39:15 +08:00
|
|
|
|
2012-01-13 21:46:36 +08:00
|
|
|
delsys = c->delivery_system;
|
2013-03-20 21:39:31 +08:00
|
|
|
memset(c, 0, offsetof(struct dtv_frontend_properties, strength));
|
2012-01-13 21:46:36 +08:00
|
|
|
c->delivery_system = delsys;
|
2011-05-09 07:03:39 +08:00
|
|
|
|
|
|
|
c->state = DTV_CLEAR;
|
2012-01-02 03:11:10 +08:00
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Clearing cache for delivery system %d\n",
|
|
|
|
__func__, c->delivery_system);
|
2012-01-02 03:11:10 +08:00
|
|
|
|
2011-05-09 07:03:39 +08:00
|
|
|
c->transmission_mode = TRANSMISSION_MODE_AUTO;
|
2012-01-02 03:11:10 +08:00
|
|
|
c->bandwidth_hz = 0; /* AUTO */
|
2011-05-09 07:03:39 +08:00
|
|
|
c->guard_interval = GUARD_INTERVAL_AUTO;
|
|
|
|
c->hierarchy = HIERARCHY_AUTO;
|
2012-01-02 03:11:10 +08:00
|
|
|
c->symbol_rate = 0;
|
2011-05-09 07:03:39 +08:00
|
|
|
c->code_rate_HP = FEC_AUTO;
|
|
|
|
c->code_rate_LP = FEC_AUTO;
|
2012-01-02 03:11:10 +08:00
|
|
|
c->fec_inner = FEC_AUTO;
|
2011-11-11 22:46:23 +08:00
|
|
|
c->rolloff = ROLLOFF_AUTO;
|
2012-01-02 03:11:10 +08:00
|
|
|
c->voltage = SEC_VOLTAGE_OFF;
|
|
|
|
c->sectone = SEC_TONE_OFF;
|
|
|
|
c->pilot = PILOT_AUTO;
|
2011-05-09 07:03:39 +08:00
|
|
|
|
2012-01-02 03:11:15 +08:00
|
|
|
c->isdbt_partial_reception = 0;
|
|
|
|
c->isdbt_sb_mode = 0;
|
|
|
|
c->isdbt_sb_subchannel = 0;
|
|
|
|
c->isdbt_sb_segment_idx = 0;
|
|
|
|
c->isdbt_sb_segment_count = 0;
|
|
|
|
c->isdbt_layer_enabled = 0;
|
2009-08-04 01:39:15 +08:00
|
|
|
for (i = 0; i < 3; i++) {
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[i].fec = FEC_AUTO;
|
|
|
|
c->layer[i].modulation = QAM_AUTO;
|
2012-01-02 03:11:15 +08:00
|
|
|
c->layer[i].interleaving = 0;
|
|
|
|
c->layer[i].segment_count = 0;
|
2009-08-04 01:39:15 +08:00
|
|
|
}
|
|
|
|
|
2012-09-13 21:13:30 +08:00
|
|
|
c->stream_id = NO_STREAM_ID_FILTER;
|
2012-01-02 03:11:10 +08:00
|
|
|
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
switch (c->delivery_system) {
|
|
|
|
case SYS_DVBS:
|
|
|
|
case SYS_DVBS2:
|
|
|
|
case SYS_TURBO:
|
|
|
|
c->modulation = QPSK; /* implied for DVB-S in legacy API */
|
|
|
|
c->rolloff = ROLLOFF_35;/* implied for DVB-S */
|
|
|
|
break;
|
|
|
|
case SYS_ATSC:
|
|
|
|
c->modulation = VSB_8;
|
|
|
|
break;
|
2014-10-31 21:19:39 +08:00
|
|
|
case SYS_ISDBS:
|
|
|
|
c->symbol_rate = 28860000;
|
|
|
|
c->rolloff = ROLLOFF_35;
|
|
|
|
c->bandwidth_hz = c->symbol_rate / 100 * 135;
|
|
|
|
break;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
default:
|
|
|
|
c->modulation = QAM_AUTO;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2012-10-03 15:28:56 +08:00
|
|
|
c->lna = LNA_AUTO;
|
|
|
|
|
2009-08-04 01:39:15 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define _DTV_CMD(n, s, b) \
|
|
|
|
[n] = { \
|
|
|
|
.name = #n, \
|
|
|
|
.cmd = n, \
|
|
|
|
.set = s,\
|
|
|
|
.buffer = b \
|
|
|
|
}
|
|
|
|
|
2011-05-26 18:54:14 +08:00
|
|
|
static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
|
2009-10-24 07:09:42 +08:00
|
|
|
_DTV_CMD(DTV_TUNE, 1, 0),
|
|
|
|
_DTV_CMD(DTV_CLEAR, 1, 0),
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
|
|
|
|
/* Set */
|
2009-10-24 07:09:42 +08:00
|
|
|
_DTV_CMD(DTV_FREQUENCY, 1, 0),
|
|
|
|
_DTV_CMD(DTV_BANDWIDTH_HZ, 1, 0),
|
|
|
|
_DTV_CMD(DTV_MODULATION, 1, 0),
|
|
|
|
_DTV_CMD(DTV_INVERSION, 1, 0),
|
|
|
|
_DTV_CMD(DTV_DISEQC_MASTER, 1, 1),
|
|
|
|
_DTV_CMD(DTV_SYMBOL_RATE, 1, 0),
|
|
|
|
_DTV_CMD(DTV_INNER_FEC, 1, 0),
|
|
|
|
_DTV_CMD(DTV_VOLTAGE, 1, 0),
|
|
|
|
_DTV_CMD(DTV_TONE, 1, 0),
|
|
|
|
_DTV_CMD(DTV_PILOT, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ROLLOFF, 1, 0),
|
|
|
|
_DTV_CMD(DTV_DELIVERY_SYSTEM, 1, 0),
|
|
|
|
_DTV_CMD(DTV_HIERARCHY, 1, 0),
|
|
|
|
_DTV_CMD(DTV_CODE_RATE_HP, 1, 0),
|
|
|
|
_DTV_CMD(DTV_CODE_RATE_LP, 1, 0),
|
|
|
|
_DTV_CMD(DTV_GUARD_INTERVAL, 1, 0),
|
|
|
|
_DTV_CMD(DTV_TRANSMISSION_MODE, 1, 0),
|
2012-08-13 09:33:21 +08:00
|
|
|
_DTV_CMD(DTV_INTERLEAVING, 1, 0),
|
2009-08-04 01:39:15 +08:00
|
|
|
|
|
|
|
_DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_SB_SUBCHANNEL_ID, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_SB_SEGMENT_IDX, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_SB_SEGMENT_COUNT, 1, 0),
|
2009-08-14 16:24:19 +08:00
|
|
|
_DTV_CMD(DTV_ISDBT_LAYER_ENABLED, 1, 0),
|
2009-08-04 01:39:15 +08:00
|
|
|
_DTV_CMD(DTV_ISDBT_LAYERA_FEC, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_LAYERA_MODULATION, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_LAYERA_SEGMENT_COUNT, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_LAYERA_TIME_INTERLEAVING, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_LAYERB_FEC, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_LAYERB_MODULATION, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_LAYERB_SEGMENT_COUNT, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_LAYERB_TIME_INTERLEAVING, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_LAYERC_FEC, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_LAYERC_MODULATION, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0),
|
|
|
|
|
2012-09-13 21:13:30 +08:00
|
|
|
_DTV_CMD(DTV_STREAM_ID, 1, 0),
|
|
|
|
_DTV_CMD(DTV_DVBT2_PLP_ID_LEGACY, 1, 0),
|
2012-07-12 08:54:50 +08:00
|
|
|
_DTV_CMD(DTV_LNA, 1, 0),
|
2009-09-18 22:17:54 +08:00
|
|
|
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
/* Get */
|
2009-10-24 07:09:42 +08:00
|
|
|
_DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
|
|
|
|
_DTV_CMD(DTV_API_VERSION, 0, 0),
|
2011-11-14 05:47:44 +08:00
|
|
|
|
|
|
|
_DTV_CMD(DTV_ENUM_DELSYS, 0, 0),
|
2012-01-30 02:44:58 +08:00
|
|
|
|
|
|
|
_DTV_CMD(DTV_ATSCMH_PARADE_ID, 1, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_RS_FRAME_ENSEMBLE, 1, 0),
|
|
|
|
|
|
|
|
_DTV_CMD(DTV_ATSCMH_FIC_VER, 0, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_NOG, 0, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_TNOG, 0, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_SGN, 0, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_PRC, 0, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_RS_FRAME_MODE, 0, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_RS_CODE_MODE_PRI, 0, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_RS_CODE_MODE_SEC, 0, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_SCCC_BLOCK_MODE, 0, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_A, 0, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_B, 0, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_C, 0, 0),
|
|
|
|
_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_D, 0, 0),
|
2013-01-08 02:41:35 +08:00
|
|
|
|
|
|
|
/* Statistics API */
|
|
|
|
_DTV_CMD(DTV_STAT_SIGNAL_STRENGTH, 0, 0),
|
|
|
|
_DTV_CMD(DTV_STAT_CNR, 0, 0),
|
|
|
|
_DTV_CMD(DTV_STAT_PRE_ERROR_BIT_COUNT, 0, 0),
|
|
|
|
_DTV_CMD(DTV_STAT_PRE_TOTAL_BIT_COUNT, 0, 0),
|
|
|
|
_DTV_CMD(DTV_STAT_POST_ERROR_BIT_COUNT, 0, 0),
|
|
|
|
_DTV_CMD(DTV_STAT_POST_TOTAL_BIT_COUNT, 0, 0),
|
|
|
|
_DTV_CMD(DTV_STAT_ERROR_BLOCK_COUNT, 0, 0),
|
|
|
|
_DTV_CMD(DTV_STAT_TOTAL_BLOCK_COUNT, 0, 0),
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
};
|
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
static void dtv_property_dump(struct dvb_frontend *fe, struct dtv_property *tvp)
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2011-07-15 19:49:06 +08:00
|
|
|
if (tvp->cmd <= 0 || tvp->cmd > DTV_MAX_COMMAND) {
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_warn(fe->dvb->device, "%s: tvp.cmd = 0x%08x undefined\n",
|
|
|
|
__func__, tvp->cmd);
|
2008-10-03 22:50:00 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: tvp.cmd = 0x%08x (%s)\n", __func__,
|
|
|
|
tvp->cmd, dtv_cmds[tvp->cmd].name);
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
if (dtv_cmds[tvp->cmd].buffer) {
|
|
|
|
dev_dbg(fe->dvb->device, "%s: tvp.u.buffer.len = 0x%02x\n",
|
|
|
|
__func__, tvp->u.buffer.len);
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
|
|
|
|
for(i = 0; i < tvp->u.buffer.len; i++)
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device,
|
|
|
|
"%s: tvp.u.buffer.data[0x%02x] = 0x%02x\n",
|
|
|
|
__func__, i, tvp->u.buffer.data[i]);
|
|
|
|
} else {
|
|
|
|
dev_dbg(fe->dvb->device, "%s: tvp.u.data = 0x%08x\n", __func__,
|
|
|
|
tvp->u.data);
|
|
|
|
}
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
}
|
|
|
|
|
2008-09-12 10:52:32 +08:00
|
|
|
/* Synchronise the legacy tuning parameters into the cache, so that demodulator
|
|
|
|
* drivers can use a single set_frontend tuning function, regardless of whether
|
|
|
|
* it's being used for the legacy or new API, reducing code and complexity.
|
|
|
|
*/
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
static int dtv_property_cache_sync(struct dvb_frontend *fe,
|
|
|
|
struct dtv_frontend_properties *c,
|
|
|
|
const struct dvb_frontend_parameters *p)
|
2008-09-12 10:52:32 +08:00
|
|
|
{
|
|
|
|
c->frequency = p->frequency;
|
|
|
|
c->inversion = p->inversion;
|
|
|
|
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
switch (dvbv3_type(c->delivery_system)) {
|
|
|
|
case DVBV3_QPSK:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Preparing QPSK req\n", __func__);
|
2008-09-12 10:52:32 +08:00
|
|
|
c->symbol_rate = p->u.qpsk.symbol_rate;
|
|
|
|
c->fec_inner = p->u.qpsk.fec_inner;
|
|
|
|
break;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
case DVBV3_QAM:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Preparing QAM req\n", __func__);
|
2008-09-12 10:52:32 +08:00
|
|
|
c->symbol_rate = p->u.qam.symbol_rate;
|
|
|
|
c->fec_inner = p->u.qam.fec_inner;
|
|
|
|
c->modulation = p->u.qam.modulation;
|
|
|
|
break;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
case DVBV3_OFDM:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Preparing OFDM req\n", __func__);
|
|
|
|
|
2012-01-02 03:11:11 +08:00
|
|
|
switch (p->u.ofdm.bandwidth) {
|
|
|
|
case BANDWIDTH_10_MHZ:
|
|
|
|
c->bandwidth_hz = 10000000;
|
|
|
|
break;
|
|
|
|
case BANDWIDTH_8_MHZ:
|
2008-09-14 03:56:34 +08:00
|
|
|
c->bandwidth_hz = 8000000;
|
2012-01-02 03:11:11 +08:00
|
|
|
break;
|
|
|
|
case BANDWIDTH_7_MHZ:
|
|
|
|
c->bandwidth_hz = 7000000;
|
|
|
|
break;
|
|
|
|
case BANDWIDTH_6_MHZ:
|
|
|
|
c->bandwidth_hz = 6000000;
|
|
|
|
break;
|
|
|
|
case BANDWIDTH_5_MHZ:
|
|
|
|
c->bandwidth_hz = 5000000;
|
|
|
|
break;
|
|
|
|
case BANDWIDTH_1_712_MHZ:
|
|
|
|
c->bandwidth_hz = 1712000;
|
|
|
|
break;
|
|
|
|
case BANDWIDTH_AUTO:
|
2008-09-14 03:56:34 +08:00
|
|
|
c->bandwidth_hz = 0;
|
2012-01-02 03:11:11 +08:00
|
|
|
}
|
|
|
|
|
2008-09-12 10:52:32 +08:00
|
|
|
c->code_rate_HP = p->u.ofdm.code_rate_HP;
|
|
|
|
c->code_rate_LP = p->u.ofdm.code_rate_LP;
|
|
|
|
c->modulation = p->u.ofdm.constellation;
|
|
|
|
c->transmission_mode = p->u.ofdm.transmission_mode;
|
|
|
|
c->guard_interval = p->u.ofdm.guard_interval;
|
|
|
|
c->hierarchy = p->u.ofdm.hierarchy_information;
|
|
|
|
break;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
case DVBV3_ATSC:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Preparing ATSC req\n", __func__);
|
2008-09-12 10:52:32 +08:00
|
|
|
c->modulation = p->u.vsb.modulation;
|
2012-01-30 02:44:58 +08:00
|
|
|
if (c->delivery_system == SYS_ATSCMH)
|
|
|
|
break;
|
2008-09-12 11:53:50 +08:00
|
|
|
if ((c->modulation == VSB_8) || (c->modulation == VSB_16))
|
|
|
|
c->delivery_system = SYS_ATSC;
|
|
|
|
else
|
|
|
|
c->delivery_system = SYS_DVBC_ANNEX_B;
|
2008-09-12 10:52:32 +08:00
|
|
|
break;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
case DVBV3_UNKNOWN:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_err(fe->dvb->device,
|
|
|
|
"%s: doesn't know how to handle a DVBv3 call to delivery system %i\n",
|
|
|
|
__func__, c->delivery_system);
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
return -EINVAL;
|
2008-09-12 10:52:32 +08:00
|
|
|
}
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
|
|
|
|
return 0;
|
2008-09-12 10:52:32 +08:00
|
|
|
}
|
|
|
|
|
2008-09-12 11:27:13 +08:00
|
|
|
/* Ensure the cached values are set correctly in the frontend
|
|
|
|
* legacy tuning structures, for the advanced tuning API.
|
|
|
|
*/
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
static int dtv_property_legacy_params_sync(struct dvb_frontend *fe,
|
2011-12-23 01:47:48 +08:00
|
|
|
struct dvb_frontend_parameters *p)
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
{
|
2011-05-09 07:03:35 +08:00
|
|
|
const struct dtv_frontend_properties *c = &fe->dtv_property_cache;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
|
2008-09-12 11:27:13 +08:00
|
|
|
p->frequency = c->frequency;
|
|
|
|
p->inversion = c->inversion;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
switch (dvbv3_type(c->delivery_system)) {
|
|
|
|
case DVBV3_UNKNOWN:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_err(fe->dvb->device,
|
|
|
|
"%s: doesn't know how to handle a DVBv3 call to delivery system %i\n",
|
|
|
|
__func__, c->delivery_system);
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
return -EINVAL;
|
|
|
|
case DVBV3_QPSK:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Preparing QPSK req\n", __func__);
|
2008-09-12 11:27:13 +08:00
|
|
|
p->u.qpsk.symbol_rate = c->symbol_rate;
|
|
|
|
p->u.qpsk.fec_inner = c->fec_inner;
|
|
|
|
break;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
case DVBV3_QAM:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Preparing QAM req\n", __func__);
|
2008-09-12 11:27:13 +08:00
|
|
|
p->u.qam.symbol_rate = c->symbol_rate;
|
|
|
|
p->u.qam.fec_inner = c->fec_inner;
|
|
|
|
p->u.qam.modulation = c->modulation;
|
|
|
|
break;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
case DVBV3_OFDM:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Preparing OFDM req\n", __func__);
|
2012-01-02 03:11:11 +08:00
|
|
|
switch (c->bandwidth_hz) {
|
|
|
|
case 10000000:
|
|
|
|
p->u.ofdm.bandwidth = BANDWIDTH_10_MHZ;
|
|
|
|
break;
|
|
|
|
case 8000000:
|
2008-09-14 03:56:34 +08:00
|
|
|
p->u.ofdm.bandwidth = BANDWIDTH_8_MHZ;
|
2012-01-02 03:11:11 +08:00
|
|
|
break;
|
|
|
|
case 7000000:
|
|
|
|
p->u.ofdm.bandwidth = BANDWIDTH_7_MHZ;
|
|
|
|
break;
|
|
|
|
case 6000000:
|
|
|
|
p->u.ofdm.bandwidth = BANDWIDTH_6_MHZ;
|
|
|
|
break;
|
|
|
|
case 5000000:
|
|
|
|
p->u.ofdm.bandwidth = BANDWIDTH_5_MHZ;
|
|
|
|
break;
|
|
|
|
case 1712000:
|
|
|
|
p->u.ofdm.bandwidth = BANDWIDTH_1_712_MHZ;
|
|
|
|
break;
|
|
|
|
case 0:
|
|
|
|
default:
|
2008-09-14 03:56:34 +08:00
|
|
|
p->u.ofdm.bandwidth = BANDWIDTH_AUTO;
|
2012-01-02 03:11:11 +08:00
|
|
|
}
|
2008-09-12 11:27:13 +08:00
|
|
|
p->u.ofdm.code_rate_HP = c->code_rate_HP;
|
|
|
|
p->u.ofdm.code_rate_LP = c->code_rate_LP;
|
|
|
|
p->u.ofdm.constellation = c->modulation;
|
|
|
|
p->u.ofdm.transmission_mode = c->transmission_mode;
|
|
|
|
p->u.ofdm.guard_interval = c->guard_interval;
|
|
|
|
p->u.ofdm.hierarchy_information = c->hierarchy;
|
|
|
|
break;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
case DVBV3_ATSC:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Preparing VSB req\n", __func__);
|
2008-09-12 11:27:13 +08:00
|
|
|
p->u.vsb.modulation = c->modulation;
|
|
|
|
break;
|
|
|
|
}
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
return 0;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
}
|
|
|
|
|
2011-12-23 01:47:48 +08:00
|
|
|
/**
|
|
|
|
* dtv_get_frontend - calls a callback for retrieving DTV parameters
|
|
|
|
* @fe: struct dvb_frontend pointer
|
|
|
|
* @c: struct dtv_frontend_properties pointer (DVBv5 cache)
|
|
|
|
* @p_out struct dvb_frontend_parameters pointer (DVBv3 FE struct)
|
|
|
|
*
|
|
|
|
* This routine calls either the DVBv3 or DVBv5 get_frontend call.
|
|
|
|
* If c is not null, it will update the DVBv5 cache struct pointed by it.
|
|
|
|
* If p_out is not null, it will update the DVBv3 params pointed by it.
|
|
|
|
*/
|
|
|
|
static int dtv_get_frontend(struct dvb_frontend *fe,
|
|
|
|
struct dvb_frontend_parameters *p_out)
|
|
|
|
{
|
|
|
|
int r;
|
|
|
|
|
|
|
|
if (fe->ops.get_frontend) {
|
[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>
2011-12-30 22:30:21 +08:00
|
|
|
r = fe->ops.get_frontend(fe);
|
2011-12-23 01:47:48 +08:00
|
|
|
if (unlikely(r < 0))
|
|
|
|
return r;
|
[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>
2011-12-30 22:30:21 +08:00
|
|
|
if (p_out)
|
2011-12-23 01:47:48 +08:00
|
|
|
dtv_property_legacy_params_sync(fe, p_out);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
[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>
2011-12-30 22:30:21 +08:00
|
|
|
/* As everything is in cache, get_frontend fops are always supported */
|
2011-12-27 03:43:32 +08:00
|
|
|
return 0;
|
2011-12-23 01:47:48 +08:00
|
|
|
}
|
|
|
|
|
2010-04-27 06:24:00 +08:00
|
|
|
static int dvb_frontend_ioctl_legacy(struct file *file,
|
2008-09-05 08:19:43 +08:00
|
|
|
unsigned int cmd, void *parg);
|
2010-04-27 06:24:00 +08:00
|
|
|
static int dvb_frontend_ioctl_properties(struct file *file,
|
2008-09-05 08:19:43 +08:00
|
|
|
unsigned int cmd, void *parg);
|
|
|
|
|
2009-01-05 12:19:06 +08:00
|
|
|
static int dtv_property_process_get(struct dvb_frontend *fe,
|
2011-12-23 01:47:48 +08:00
|
|
|
const struct dtv_frontend_properties *c,
|
2009-01-05 12:19:06 +08:00
|
|
|
struct dtv_property *tvp,
|
2010-04-27 06:24:00 +08:00
|
|
|
struct file *file)
|
2008-09-12 12:34:28 +08:00
|
|
|
{
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
int r, ncaps;
|
2008-09-12 12:37:37 +08:00
|
|
|
|
2008-09-12 12:34:28 +08:00
|
|
|
switch(tvp->cmd) {
|
2011-11-14 05:47:44 +08:00
|
|
|
case DTV_ENUM_DELSYS:
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
ncaps = 0;
|
2014-03-06 01:08:15 +08:00
|
|
|
while (ncaps < MAX_DELSYS && fe->ops.delsys[ncaps]) {
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
tvp->u.buffer.data[ncaps] = fe->ops.delsys[ncaps];
|
|
|
|
ncaps++;
|
|
|
|
}
|
|
|
|
tvp->u.buffer.len = ncaps;
|
2011-11-14 05:47:44 +08:00
|
|
|
break;
|
2008-09-12 12:34:28 +08:00
|
|
|
case DTV_FREQUENCY:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->frequency;
|
2008-09-12 12:34:28 +08:00
|
|
|
break;
|
|
|
|
case DTV_MODULATION:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->modulation;
|
2008-09-12 12:34:28 +08:00
|
|
|
break;
|
2008-09-14 03:56:34 +08:00
|
|
|
case DTV_BANDWIDTH_HZ:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->bandwidth_hz;
|
2008-09-12 12:34:28 +08:00
|
|
|
break;
|
|
|
|
case DTV_INVERSION:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->inversion;
|
2008-09-12 12:34:28 +08:00
|
|
|
break;
|
|
|
|
case DTV_SYMBOL_RATE:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->symbol_rate;
|
2008-09-12 12:34:28 +08:00
|
|
|
break;
|
|
|
|
case DTV_INNER_FEC:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->fec_inner;
|
2008-09-12 12:34:28 +08:00
|
|
|
break;
|
|
|
|
case DTV_PILOT:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->pilot;
|
2008-09-12 12:34:28 +08:00
|
|
|
break;
|
|
|
|
case DTV_ROLLOFF:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->rolloff;
|
2008-09-12 12:34:28 +08:00
|
|
|
break;
|
|
|
|
case DTV_DELIVERY_SYSTEM:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->delivery_system;
|
2008-09-12 12:34:28 +08:00
|
|
|
break;
|
|
|
|
case DTV_VOLTAGE:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->voltage;
|
2008-09-12 12:34:28 +08:00
|
|
|
break;
|
|
|
|
case DTV_TONE:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->sectone;
|
2008-09-12 12:34:28 +08:00
|
|
|
break;
|
2008-09-26 11:29:49 +08:00
|
|
|
case DTV_API_VERSION:
|
|
|
|
tvp->u.data = (DVB_API_VERSION << 8) | DVB_API_VERSION_MINOR;
|
|
|
|
break;
|
2008-10-07 08:55:46 +08:00
|
|
|
case DTV_CODE_RATE_HP:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->code_rate_HP;
|
2008-10-07 08:55:46 +08:00
|
|
|
break;
|
|
|
|
case DTV_CODE_RATE_LP:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->code_rate_LP;
|
2008-10-07 08:55:46 +08:00
|
|
|
break;
|
2008-10-07 08:56:59 +08:00
|
|
|
case DTV_GUARD_INTERVAL:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->guard_interval;
|
2008-10-07 08:56:59 +08:00
|
|
|
break;
|
|
|
|
case DTV_TRANSMISSION_MODE:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->transmission_mode;
|
2008-10-07 08:56:59 +08:00
|
|
|
break;
|
2008-10-07 09:01:47 +08:00
|
|
|
case DTV_HIERARCHY:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->hierarchy;
|
2008-10-07 09:01:47 +08:00
|
|
|
break;
|
2012-08-13 09:33:21 +08:00
|
|
|
case DTV_INTERLEAVING:
|
|
|
|
tvp->u.data = c->interleaving;
|
|
|
|
break;
|
2009-08-04 01:39:15 +08:00
|
|
|
|
|
|
|
/* ISDB-T Support here */
|
|
|
|
case DTV_ISDBT_PARTIAL_RECEPTION:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->isdbt_partial_reception;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_SOUND_BROADCASTING:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->isdbt_sb_mode;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_SB_SUBCHANNEL_ID:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->isdbt_sb_subchannel;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_SB_SEGMENT_IDX:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->isdbt_sb_segment_idx;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_SB_SEGMENT_COUNT:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->isdbt_sb_segment_count;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
2009-08-14 16:24:19 +08:00
|
|
|
case DTV_ISDBT_LAYER_ENABLED:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->isdbt_layer_enabled;
|
2009-08-14 16:24:19 +08:00
|
|
|
break;
|
2009-08-04 01:39:15 +08:00
|
|
|
case DTV_ISDBT_LAYERA_FEC:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->layer[0].fec;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERA_MODULATION:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->layer[0].modulation;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERA_SEGMENT_COUNT:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->layer[0].segment_count;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERA_TIME_INTERLEAVING:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->layer[0].interleaving;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERB_FEC:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->layer[1].fec;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERB_MODULATION:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->layer[1].modulation;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERB_SEGMENT_COUNT:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->layer[1].segment_count;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERB_TIME_INTERLEAVING:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->layer[1].interleaving;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERC_FEC:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->layer[2].fec;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERC_MODULATION:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->layer[2].modulation;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERC_SEGMENT_COUNT:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->layer[2].segment_count;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
|
2011-05-09 07:03:39 +08:00
|
|
|
tvp->u.data = c->layer[2].interleaving;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
2012-09-13 21:13:30 +08:00
|
|
|
|
|
|
|
/* Multistream support */
|
|
|
|
case DTV_STREAM_ID:
|
|
|
|
case DTV_DVBT2_PLP_ID_LEGACY:
|
|
|
|
tvp->u.data = c->stream_id;
|
2011-05-13 05:11:06 +08:00
|
|
|
break;
|
2012-01-30 02:44:58 +08:00
|
|
|
|
|
|
|
/* ATSC-MH */
|
|
|
|
case DTV_ATSCMH_FIC_VER:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_fic_ver;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_PARADE_ID:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_parade_id;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_NOG:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_nog;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_TNOG:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_tnog;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_SGN:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_sgn;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_PRC:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_prc;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_RS_FRAME_MODE:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_rs_frame_mode;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_RS_FRAME_ENSEMBLE:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_rs_frame_ensemble;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_RS_CODE_MODE_PRI:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_rs_code_mode_pri;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_RS_CODE_MODE_SEC:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_rs_code_mode_sec;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_SCCC_BLOCK_MODE:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_sccc_block_mode;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_SCCC_CODE_MODE_A:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_sccc_code_mode_a;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_SCCC_CODE_MODE_B:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_sccc_code_mode_b;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_SCCC_CODE_MODE_C:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_sccc_code_mode_c;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_SCCC_CODE_MODE_D:
|
|
|
|
tvp->u.data = fe->dtv_property_cache.atscmh_sccc_code_mode_d;
|
|
|
|
break;
|
|
|
|
|
2012-10-03 15:28:56 +08:00
|
|
|
case DTV_LNA:
|
|
|
|
tvp->u.data = c->lna;
|
|
|
|
break;
|
|
|
|
|
2013-01-08 02:41:35 +08:00
|
|
|
/* Fill quality measures */
|
|
|
|
case DTV_STAT_SIGNAL_STRENGTH:
|
|
|
|
tvp->u.st = c->strength;
|
|
|
|
break;
|
|
|
|
case DTV_STAT_CNR:
|
|
|
|
tvp->u.st = c->cnr;
|
|
|
|
break;
|
|
|
|
case DTV_STAT_PRE_ERROR_BIT_COUNT:
|
|
|
|
tvp->u.st = c->pre_bit_error;
|
|
|
|
break;
|
|
|
|
case DTV_STAT_PRE_TOTAL_BIT_COUNT:
|
|
|
|
tvp->u.st = c->pre_bit_count;
|
|
|
|
break;
|
|
|
|
case DTV_STAT_POST_ERROR_BIT_COUNT:
|
|
|
|
tvp->u.st = c->post_bit_error;
|
|
|
|
break;
|
|
|
|
case DTV_STAT_POST_TOTAL_BIT_COUNT:
|
|
|
|
tvp->u.st = c->post_bit_count;
|
|
|
|
break;
|
|
|
|
case DTV_STAT_ERROR_BLOCK_COUNT:
|
|
|
|
tvp->u.st = c->block_error;
|
|
|
|
break;
|
|
|
|
case DTV_STAT_TOTAL_BLOCK_COUNT:
|
|
|
|
tvp->u.st = c->block_count;
|
|
|
|
break;
|
2008-09-12 12:34:28 +08:00
|
|
|
default:
|
2013-01-24 04:06:02 +08:00
|
|
|
dev_dbg(fe->dvb->device,
|
|
|
|
"%s: FE property %d doesn't exist\n",
|
|
|
|
__func__, tvp->cmd);
|
2011-05-09 07:03:34 +08:00
|
|
|
return -EINVAL;
|
2008-09-12 12:34:28 +08:00
|
|
|
}
|
|
|
|
|
2011-05-09 07:03:36 +08:00
|
|
|
/* Allow the frontend to override outgoing properties */
|
|
|
|
if (fe->ops.get_property) {
|
|
|
|
r = fe->ops.get_property(fe, tvp);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dtv_property_dump(fe, tvp);
|
2010-01-01 04:49:32 +08:00
|
|
|
|
2011-05-09 07:03:34 +08:00
|
|
|
return 0;
|
2008-09-12 12:34:28 +08:00
|
|
|
}
|
|
|
|
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
static int dtv_set_frontend(struct dvb_frontend *fe);
|
|
|
|
|
2012-01-02 03:11:14 +08:00
|
|
|
static bool is_dvbv3_delsys(u32 delsys)
|
|
|
|
{
|
|
|
|
bool status;
|
|
|
|
|
|
|
|
status = (delsys == SYS_DVBT) || (delsys == SYS_DVBC_ANNEX_A) ||
|
|
|
|
(delsys == SYS_DVBS) || (delsys == SYS_ATSC);
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2013-03-19 02:25:37 +08:00
|
|
|
/**
|
|
|
|
* emulate_delivery_system - emulate a DVBv5 delivery system with a DVBv3 type
|
|
|
|
* @fe: struct frontend;
|
|
|
|
* @delsys: DVBv5 type that will be used for emulation
|
|
|
|
*
|
|
|
|
* Provides emulation for delivery systems that are compatible with the old
|
|
|
|
* DVBv3 call. Among its usages, it provices support for ISDB-T, and allows
|
|
|
|
* using a DVB-S2 only frontend just like it were a DVB-S, if the frontent
|
|
|
|
* parameters are compatible with DVB-S spec.
|
|
|
|
*/
|
|
|
|
static int emulate_delivery_system(struct dvb_frontend *fe, u32 delsys)
|
2012-01-02 03:11:14 +08:00
|
|
|
{
|
2013-03-19 02:25:36 +08:00
|
|
|
int i;
|
2012-01-02 03:11:14 +08:00
|
|
|
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
|
|
|
|
|
2012-04-18 05:32:19 +08:00
|
|
|
c->delivery_system = delsys;
|
|
|
|
|
2012-01-02 03:11:14 +08:00
|
|
|
/*
|
2013-03-19 02:25:37 +08:00
|
|
|
* If the call is for ISDB-T, put it into full-seg, auto mode, TV
|
2012-01-02 03:11:14 +08:00
|
|
|
*/
|
2013-03-19 02:25:37 +08:00
|
|
|
if (c->delivery_system == SYS_ISDBT) {
|
|
|
|
dev_dbg(fe->dvb->device,
|
|
|
|
"%s: Using defaults for SYS_ISDBT\n",
|
|
|
|
__func__);
|
2012-01-02 03:11:14 +08:00
|
|
|
|
2013-03-19 02:25:37 +08:00
|
|
|
if (!c->bandwidth_hz)
|
|
|
|
c->bandwidth_hz = 6000000;
|
|
|
|
|
|
|
|
c->isdbt_partial_reception = 0;
|
|
|
|
c->isdbt_sb_mode = 0;
|
|
|
|
c->isdbt_sb_subchannel = 0;
|
|
|
|
c->isdbt_sb_segment_idx = 0;
|
|
|
|
c->isdbt_sb_segment_count = 0;
|
|
|
|
c->isdbt_layer_enabled = 7;
|
|
|
|
for (i = 0; i < 3; i++) {
|
|
|
|
c->layer[i].fec = FEC_AUTO;
|
|
|
|
c->layer[i].modulation = QAM_AUTO;
|
|
|
|
c->layer[i].interleaving = 0;
|
|
|
|
c->layer[i].segment_count = 0;
|
2012-01-02 03:11:14 +08:00
|
|
|
}
|
|
|
|
}
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: change delivery system on cache to %d\n",
|
2013-03-19 02:25:37 +08:00
|
|
|
__func__, c->delivery_system);
|
2012-01-05 22:28:20 +08:00
|
|
|
|
2012-01-02 03:11:14 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-03-19 02:25:37 +08:00
|
|
|
/**
|
|
|
|
* dvbv5_set_delivery_system - Sets the delivery system for a DVBv5 API call
|
|
|
|
* @fe: frontend struct
|
|
|
|
* @desired_system: delivery system requested by the user
|
|
|
|
*
|
|
|
|
* A DVBv5 call know what's the desired system it wants. So, set it.
|
|
|
|
*
|
|
|
|
* There are, however, a few known issues with early DVBv5 applications that
|
|
|
|
* are also handled by this logic:
|
|
|
|
*
|
|
|
|
* 1) Some early apps use SYS_UNDEFINED as the desired delivery system.
|
|
|
|
* This is an API violation, but, as we don't want to break userspace,
|
|
|
|
* convert it to the first supported delivery system.
|
|
|
|
* 2) Some apps might be using a DVBv5 call in a wrong way, passing, for
|
|
|
|
* example, SYS_DVBT instead of SYS_ISDBT. This is because early usage of
|
|
|
|
* ISDB-T provided backward compat with DVB-T.
|
|
|
|
*/
|
2013-03-19 02:25:36 +08:00
|
|
|
static int dvbv5_set_delivery_system(struct dvb_frontend *fe,
|
|
|
|
u32 desired_system)
|
|
|
|
{
|
|
|
|
int ncaps;
|
|
|
|
u32 delsys = SYS_UNDEFINED;
|
|
|
|
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
|
|
|
|
enum dvbv3_emulation_type type;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It was reported that some old DVBv5 applications were
|
|
|
|
* filling delivery_system with SYS_UNDEFINED. If this happens,
|
|
|
|
* assume that the application wants to use the first supported
|
|
|
|
* delivery system.
|
|
|
|
*/
|
2013-03-19 02:25:37 +08:00
|
|
|
if (desired_system == SYS_UNDEFINED)
|
|
|
|
desired_system = fe->ops.delsys[0];
|
2013-03-19 02:25:36 +08:00
|
|
|
|
|
|
|
/*
|
2013-03-19 02:25:37 +08:00
|
|
|
* This is a DVBv5 call. So, it likely knows the supported
|
|
|
|
* delivery systems. So, check if the desired delivery system is
|
|
|
|
* supported
|
|
|
|
*/
|
2013-03-19 02:25:36 +08:00
|
|
|
ncaps = 0;
|
2014-03-06 01:08:15 +08:00
|
|
|
while (ncaps < MAX_DELSYS && fe->ops.delsys[ncaps]) {
|
2013-03-19 02:25:36 +08:00
|
|
|
if (fe->ops.delsys[ncaps] == desired_system) {
|
|
|
|
c->delivery_system = desired_system;
|
|
|
|
dev_dbg(fe->dvb->device,
|
|
|
|
"%s: Changing delivery system to %d\n",
|
|
|
|
__func__, desired_system);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
ncaps++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-03-19 02:25:37 +08:00
|
|
|
* The requested delivery system isn't supported. Maybe userspace
|
|
|
|
* is requesting a DVBv3 compatible delivery system.
|
|
|
|
*
|
|
|
|
* The emulation only works if the desired system is one of the
|
|
|
|
* delivery systems supported by DVBv3 API
|
2013-03-19 02:25:36 +08:00
|
|
|
*/
|
|
|
|
if (!is_dvbv3_delsys(desired_system)) {
|
|
|
|
dev_dbg(fe->dvb->device,
|
2013-03-19 02:25:37 +08:00
|
|
|
"%s: Delivery system %d not supported.\n",
|
|
|
|
__func__, desired_system);
|
2013-03-19 02:25:36 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2013-03-19 02:25:37 +08:00
|
|
|
type = dvbv3_type(desired_system);
|
|
|
|
|
2013-03-19 02:25:36 +08:00
|
|
|
/*
|
|
|
|
* Get the last non-DVBv3 delivery system that has the same type
|
|
|
|
* of the desired system
|
|
|
|
*/
|
|
|
|
ncaps = 0;
|
2014-03-06 01:08:15 +08:00
|
|
|
while (ncaps < MAX_DELSYS && fe->ops.delsys[ncaps]) {
|
2013-03-19 02:25:37 +08:00
|
|
|
if (dvbv3_type(fe->ops.delsys[ncaps]) == type)
|
2013-03-19 02:25:36 +08:00
|
|
|
delsys = fe->ops.delsys[ncaps];
|
|
|
|
ncaps++;
|
|
|
|
}
|
2013-03-19 02:25:37 +08:00
|
|
|
|
2013-03-19 02:25:36 +08:00
|
|
|
/* There's nothing compatible with the desired delivery system */
|
|
|
|
if (delsys == SYS_UNDEFINED) {
|
|
|
|
dev_dbg(fe->dvb->device,
|
2013-03-19 02:25:37 +08:00
|
|
|
"%s: Delivery system %d not supported on emulation mode.\n",
|
|
|
|
__func__, desired_system);
|
2013-03-19 02:25:36 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2013-03-19 02:25:37 +08:00
|
|
|
dev_dbg(fe->dvb->device,
|
|
|
|
"%s: Using delivery system %d emulated as if it were %d\n",
|
|
|
|
__func__, delsys, desired_system);
|
|
|
|
|
|
|
|
return emulate_delivery_system(fe, desired_system);
|
2013-03-19 02:25:36 +08:00
|
|
|
}
|
|
|
|
|
2013-03-19 02:25:37 +08:00
|
|
|
/**
|
|
|
|
* dvbv3_set_delivery_system - Sets the delivery system for a DVBv3 API call
|
|
|
|
* @fe: frontend struct
|
|
|
|
*
|
|
|
|
* A DVBv3 call doesn't know what's the desired system it wants. It also
|
|
|
|
* doesn't allow to switch between different types. Due to that, userspace
|
|
|
|
* should use DVBv5 instead.
|
|
|
|
* However, in order to avoid breaking userspace API, limited backward
|
|
|
|
* compatibility support is provided.
|
|
|
|
*
|
|
|
|
* There are some delivery systems that are incompatible with DVBv3 calls.
|
|
|
|
*
|
|
|
|
* This routine should work fine for frontends that support just one delivery
|
|
|
|
* system.
|
|
|
|
*
|
|
|
|
* For frontends that support multiple frontends:
|
|
|
|
* 1) It defaults to use the first supported delivery system. There's an
|
|
|
|
* userspace application that allows changing it at runtime;
|
|
|
|
*
|
|
|
|
* 2) If the current delivery system is not compatible with DVBv3, it gets
|
|
|
|
* the first one that it is compatible.
|
|
|
|
*
|
|
|
|
* NOTE: in order for this to work with applications like Kaffeine that
|
|
|
|
* uses a DVBv5 call for DVB-S2 and a DVBv3 call to go back to
|
|
|
|
* DVB-S, drivers that support both DVB-S and DVB-S2 should have the
|
|
|
|
* SYS_DVBS entry before the SYS_DVBS2, otherwise it won't switch back
|
|
|
|
* to DVB-S.
|
|
|
|
*/
|
2013-03-19 02:25:36 +08:00
|
|
|
static int dvbv3_set_delivery_system(struct dvb_frontend *fe)
|
|
|
|
{
|
|
|
|
int ncaps;
|
|
|
|
u32 delsys = SYS_UNDEFINED;
|
|
|
|
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
|
|
|
|
|
|
|
|
/* If not set yet, defaults to the first supported delivery system */
|
|
|
|
if (c->delivery_system == SYS_UNDEFINED)
|
|
|
|
c->delivery_system = fe->ops.delsys[0];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Trivial case: just use the current one, if it already a DVBv3
|
|
|
|
* delivery system
|
|
|
|
*/
|
|
|
|
if (is_dvbv3_delsys(c->delivery_system)) {
|
|
|
|
dev_dbg(fe->dvb->device,
|
|
|
|
"%s: Using delivery system to %d\n",
|
|
|
|
__func__, c->delivery_system);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-03-19 02:25:37 +08:00
|
|
|
* Seek for the first delivery system that it is compatible with a
|
|
|
|
* DVBv3 standard
|
2013-03-19 02:25:36 +08:00
|
|
|
*/
|
|
|
|
ncaps = 0;
|
2014-03-06 01:08:15 +08:00
|
|
|
while (ncaps < MAX_DELSYS && fe->ops.delsys[ncaps]) {
|
2013-03-19 02:25:37 +08:00
|
|
|
if (dvbv3_type(fe->ops.delsys[ncaps]) != DVBV3_UNKNOWN) {
|
|
|
|
delsys = fe->ops.delsys[ncaps];
|
2013-03-19 02:25:36 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
ncaps++;
|
|
|
|
}
|
|
|
|
if (delsys == SYS_UNDEFINED) {
|
2013-03-19 02:25:37 +08:00
|
|
|
dev_dbg(fe->dvb->device,
|
|
|
|
"%s: Couldn't find a delivery system that works with FE_SET_FRONTEND\n",
|
|
|
|
__func__);
|
|
|
|
return -EINVAL;
|
2013-03-19 02:25:36 +08:00
|
|
|
}
|
2013-03-19 02:25:37 +08:00
|
|
|
return emulate_delivery_system(fe, delsys);
|
2013-03-19 02:25:36 +08:00
|
|
|
}
|
|
|
|
|
2009-01-05 12:19:06 +08:00
|
|
|
static int dtv_property_process_set(struct dvb_frontend *fe,
|
|
|
|
struct dtv_property *tvp,
|
|
|
|
struct file *file)
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
{
|
|
|
|
int r = 0;
|
2011-05-09 07:03:39 +08:00
|
|
|
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
|
2008-09-12 12:37:37 +08:00
|
|
|
/* Allow the frontend to validate incoming properties */
|
2011-05-09 07:03:34 +08:00
|
|
|
if (fe->ops.set_property) {
|
2008-09-12 12:37:37 +08:00
|
|
|
r = fe->ops.set_property(fe, tvp);
|
2011-05-09 07:03:34 +08:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
}
|
2008-09-12 12:37:37 +08:00
|
|
|
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
switch(tvp->cmd) {
|
2008-09-11 21:23:01 +08:00
|
|
|
case DTV_CLEAR:
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
/*
|
|
|
|
* Reset a cache of data specific to the frontend here. This does
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
* not effect hardware.
|
|
|
|
*/
|
2009-08-04 01:39:15 +08:00
|
|
|
dvb_frontend_clear_cache(fe);
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
break;
|
2008-09-11 21:23:01 +08:00
|
|
|
case DTV_TUNE:
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
/* interpret the cache of data, build either a traditional frontend
|
2008-09-12 11:27:13 +08:00
|
|
|
* tunerequest so we can pass validation in the FE_SET_FRONTEND
|
|
|
|
* ioctl.
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
*/
|
2011-05-09 07:03:39 +08:00
|
|
|
c->state = tvp->cmd;
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Finalised property cache\n",
|
|
|
|
__func__);
|
2008-09-12 11:27:13 +08:00
|
|
|
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
r = dtv_set_frontend(fe);
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
break;
|
2008-09-12 12:34:28 +08:00
|
|
|
case DTV_FREQUENCY:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->frequency = tvp->u.data;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
break;
|
2008-09-12 12:34:28 +08:00
|
|
|
case DTV_MODULATION:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->modulation = tvp->u.data;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
break;
|
2008-09-14 03:56:34 +08:00
|
|
|
case DTV_BANDWIDTH_HZ:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->bandwidth_hz = tvp->u.data;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
break;
|
2008-09-12 12:34:28 +08:00
|
|
|
case DTV_INVERSION:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->inversion = tvp->u.data;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
break;
|
2008-09-12 12:34:28 +08:00
|
|
|
case DTV_SYMBOL_RATE:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->symbol_rate = tvp->u.data;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
break;
|
2008-09-12 12:34:28 +08:00
|
|
|
case DTV_INNER_FEC:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->fec_inner = tvp->u.data;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
break;
|
2008-09-12 12:34:28 +08:00
|
|
|
case DTV_PILOT:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->pilot = tvp->u.data;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
break;
|
2008-09-12 12:34:28 +08:00
|
|
|
case DTV_ROLLOFF:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->rolloff = tvp->u.data;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
break;
|
2008-09-12 12:34:28 +08:00
|
|
|
case DTV_DELIVERY_SYSTEM:
|
2013-03-19 02:25:36 +08:00
|
|
|
r = dvbv5_set_delivery_system(fe, tvp->u.data);
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
break;
|
2008-09-12 12:34:28 +08:00
|
|
|
case DTV_VOLTAGE:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->voltage = tvp->u.data;
|
2010-04-27 06:24:00 +08:00
|
|
|
r = dvb_frontend_ioctl_legacy(file, FE_SET_VOLTAGE,
|
2011-05-09 07:03:39 +08:00
|
|
|
(void *)c->voltage);
|
2008-09-05 08:19:43 +08:00
|
|
|
break;
|
2008-09-12 12:34:28 +08:00
|
|
|
case DTV_TONE:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->sectone = tvp->u.data;
|
2010-04-27 06:24:00 +08:00
|
|
|
r = dvb_frontend_ioctl_legacy(file, FE_SET_TONE,
|
2011-05-09 07:03:39 +08:00
|
|
|
(void *)c->sectone);
|
2008-09-05 08:19:43 +08:00
|
|
|
break;
|
2008-10-07 08:55:46 +08:00
|
|
|
case DTV_CODE_RATE_HP:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->code_rate_HP = tvp->u.data;
|
2008-10-07 08:55:46 +08:00
|
|
|
break;
|
|
|
|
case DTV_CODE_RATE_LP:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->code_rate_LP = tvp->u.data;
|
2008-10-07 08:55:46 +08:00
|
|
|
break;
|
2008-10-07 08:56:59 +08:00
|
|
|
case DTV_GUARD_INTERVAL:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->guard_interval = tvp->u.data;
|
2008-10-07 08:56:59 +08:00
|
|
|
break;
|
|
|
|
case DTV_TRANSMISSION_MODE:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->transmission_mode = tvp->u.data;
|
2008-10-07 08:56:59 +08:00
|
|
|
break;
|
2008-10-07 09:01:47 +08:00
|
|
|
case DTV_HIERARCHY:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->hierarchy = tvp->u.data;
|
2008-10-07 09:01:47 +08:00
|
|
|
break;
|
2012-08-13 09:33:21 +08:00
|
|
|
case DTV_INTERLEAVING:
|
|
|
|
c->interleaving = tvp->u.data;
|
|
|
|
break;
|
2009-08-04 01:39:15 +08:00
|
|
|
|
|
|
|
/* ISDB-T Support here */
|
|
|
|
case DTV_ISDBT_PARTIAL_RECEPTION:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->isdbt_partial_reception = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_SOUND_BROADCASTING:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->isdbt_sb_mode = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_SB_SUBCHANNEL_ID:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->isdbt_sb_subchannel = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_SB_SEGMENT_IDX:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->isdbt_sb_segment_idx = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_SB_SEGMENT_COUNT:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->isdbt_sb_segment_count = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
2009-08-14 16:24:19 +08:00
|
|
|
case DTV_ISDBT_LAYER_ENABLED:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->isdbt_layer_enabled = tvp->u.data;
|
2009-08-14 16:24:19 +08:00
|
|
|
break;
|
2009-08-04 01:39:15 +08:00
|
|
|
case DTV_ISDBT_LAYERA_FEC:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[0].fec = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERA_MODULATION:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[0].modulation = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERA_SEGMENT_COUNT:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[0].segment_count = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERA_TIME_INTERLEAVING:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[0].interleaving = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERB_FEC:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[1].fec = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERB_MODULATION:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[1].modulation = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERB_SEGMENT_COUNT:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[1].segment_count = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERB_TIME_INTERLEAVING:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[1].interleaving = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERC_FEC:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[2].fec = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERC_MODULATION:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[2].modulation = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERC_SEGMENT_COUNT:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[2].segment_count = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
|
|
|
case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
|
2011-05-09 07:03:39 +08:00
|
|
|
c->layer[2].interleaving = tvp->u.data;
|
2009-08-04 01:39:15 +08:00
|
|
|
break;
|
2012-09-13 21:13:30 +08:00
|
|
|
|
|
|
|
/* Multistream support */
|
|
|
|
case DTV_STREAM_ID:
|
|
|
|
case DTV_DVBT2_PLP_ID_LEGACY:
|
|
|
|
c->stream_id = tvp->u.data;
|
2009-09-18 22:17:54 +08:00
|
|
|
break;
|
2012-01-30 02:44:58 +08:00
|
|
|
|
|
|
|
/* ATSC-MH */
|
|
|
|
case DTV_ATSCMH_PARADE_ID:
|
|
|
|
fe->dtv_property_cache.atscmh_parade_id = tvp->u.data;
|
|
|
|
break;
|
|
|
|
case DTV_ATSCMH_RS_FRAME_ENSEMBLE:
|
|
|
|
fe->dtv_property_cache.atscmh_rs_frame_ensemble = tvp->u.data;
|
|
|
|
break;
|
|
|
|
|
2012-10-03 15:28:56 +08:00
|
|
|
case DTV_LNA:
|
|
|
|
c->lna = tvp->u.data;
|
|
|
|
if (fe->ops.set_lna)
|
|
|
|
r = fe->ops.set_lna(fe);
|
2014-02-16 17:36:17 +08:00
|
|
|
if (r < 0)
|
|
|
|
c->lna = LNA_AUTO;
|
2012-10-03 15:28:56 +08:00
|
|
|
break;
|
|
|
|
|
2008-09-12 12:34:28 +08:00
|
|
|
default:
|
2011-05-09 07:03:34 +08:00
|
|
|
return -EINVAL;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
}
|
|
|
|
|
2008-09-05 08:19:43 +08:00
|
|
|
return r;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
}
|
|
|
|
|
2010-04-27 06:24:00 +08:00
|
|
|
static int dvb_frontend_ioctl(struct file *file,
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned int cmd, void *parg)
|
|
|
|
{
|
|
|
|
struct dvb_device *dvbdev = file->private_data;
|
|
|
|
struct dvb_frontend *fe = dvbdev->priv;
|
2011-05-09 07:03:39 +08:00
|
|
|
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2013-02-15 23:39:31 +08:00
|
|
|
int err = -EOPNOTSUPP;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: (%d)\n", __func__, _IOC_NR(cmd));
|
2012-12-24 04:23:06 +08:00
|
|
|
if (down_interruptible(&fepriv->sem))
|
|
|
|
return -ERESTARTSYS;
|
|
|
|
|
2014-07-13 00:44:12 +08:00
|
|
|
if (fe->exit != DVB_FE_NO_EXIT) {
|
2012-12-24 04:23:06 +08:00
|
|
|
up(&fepriv->sem);
|
2005-04-17 06:20:36 +08:00
|
|
|
return -ENODEV;
|
2012-12-24 04:23:06 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if ((file->f_flags & O_ACCMODE) == O_RDONLY &&
|
|
|
|
(_IOC_DIR(cmd) != _IOC_READ || cmd == FE_GET_EVENT ||
|
2012-12-24 04:23:06 +08:00
|
|
|
cmd == FE_DISEQC_RECV_SLAVE_REPLY)) {
|
|
|
|
up(&fepriv->sem);
|
2005-04-17 06:20:36 +08:00
|
|
|
return -EPERM;
|
2012-12-24 04:23:06 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-09-05 08:19:43 +08:00
|
|
|
if ((cmd == FE_SET_PROPERTY) || (cmd == FE_GET_PROPERTY))
|
2010-04-27 06:24:00 +08:00
|
|
|
err = dvb_frontend_ioctl_properties(file, cmd, parg);
|
2008-09-14 02:09:07 +08:00
|
|
|
else {
|
2011-05-09 07:03:39 +08:00
|
|
|
c->state = DTV_UNDEFINED;
|
2010-04-27 06:24:00 +08:00
|
|
|
err = dvb_frontend_ioctl_legacy(file, cmd, parg);
|
2008-09-14 02:09:07 +08:00
|
|
|
}
|
2008-09-05 08:19:43 +08:00
|
|
|
|
|
|
|
up(&fepriv->sem);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2010-04-27 06:24:00 +08:00
|
|
|
static int dvb_frontend_ioctl_properties(struct file *file,
|
2008-09-05 08:19:43 +08:00
|
|
|
unsigned int cmd, void *parg)
|
|
|
|
{
|
|
|
|
struct dvb_device *dvbdev = file->private_data;
|
|
|
|
struct dvb_frontend *fe = dvbdev->priv;
|
[media] dvb_frontend: Don't call get_frontend() if idle
If the frontend is in idle state, don't call get_frontend.
Calling get_frontend() when the device is not tuned may
result in wrong parameters to be returned to the
userspace.
I was tempted to not call get_frontend() at all, except
inside the dvb frontend thread, but this won't work for
all cases. The ISDB-T specs (ABNT NBR 15601 and ARIB
STD-B31) allow the broadcaster to dynamically change the
channel specs at runtime. That means that an ISDB-T optimized
application may want/need to monitor the TMCC tables, decoded
at the frontends via get_frontend call.
So, let's do the simpler change here.
Eventually, the logic could be changed to work only if
the device is tuned and has lock, but, even so, the
lock is also standard-dependent. For ISDB-T, the right
lock to wait is that the demod has TMCC lock. So, drivers
may need to implement some logic to detect if the get_frontend
info was retrieved or not.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-18 02:20:37 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2011-05-09 07:03:39 +08:00
|
|
|
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
|
2008-09-13 01:49:06 +08:00
|
|
|
int err = 0;
|
2008-09-11 21:23:01 +08:00
|
|
|
|
2014-09-24 21:15:22 +08:00
|
|
|
struct dtv_properties *tvps = parg;
|
2008-09-11 21:23:01 +08:00
|
|
|
struct dtv_property *tvp = NULL;
|
|
|
|
int i;
|
2008-09-05 08:19:43 +08:00
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s:\n", __func__);
|
2008-09-05 08:19:43 +08:00
|
|
|
|
2014-09-24 21:15:22 +08:00
|
|
|
if (cmd == FE_SET_PROPERTY) {
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: properties.num = %d\n", __func__, tvps->num);
|
|
|
|
dev_dbg(fe->dvb->device, "%s: properties.props = %p\n", __func__, tvps->props);
|
2008-09-11 21:23:01 +08:00
|
|
|
|
|
|
|
/* Put an arbitrary limit on the number of messages that can
|
|
|
|
* be sent at once */
|
2008-10-07 09:46:08 +08:00
|
|
|
if ((tvps->num == 0) || (tvps->num > DTV_IOCTL_MAX_MSGS))
|
2008-09-11 21:23:01 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2010-01-16 21:25:38 +08:00
|
|
|
tvp = kmalloc(tvps->num * sizeof(struct dtv_property), GFP_KERNEL);
|
2008-09-11 21:23:01 +08:00
|
|
|
if (!tvp) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto out;
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
}
|
|
|
|
|
2014-09-24 21:15:22 +08:00
|
|
|
if (copy_from_user(tvp, (void __user *)tvps->props,
|
|
|
|
tvps->num * sizeof(struct dtv_property))) {
|
2008-09-11 21:23:01 +08:00
|
|
|
err = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2008-09-26 11:16:25 +08:00
|
|
|
for (i = 0; i < tvps->num; i++) {
|
2011-05-09 07:03:34 +08:00
|
|
|
err = dtv_property_process_set(fe, tvp + i, file);
|
|
|
|
if (err < 0)
|
|
|
|
goto out;
|
|
|
|
(tvp + i)->result = err;
|
2008-09-26 11:16:25 +08:00
|
|
|
}
|
2008-09-11 21:23:01 +08:00
|
|
|
|
2011-05-09 07:03:39 +08:00
|
|
|
if (c->state == DTV_TUNE)
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: Property cache is full, tuning\n", __func__);
|
2008-09-12 12:37:37 +08:00
|
|
|
|
2014-09-24 21:15:22 +08:00
|
|
|
} else if (cmd == FE_GET_PROPERTY) {
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: properties.num = %d\n", __func__, tvps->num);
|
|
|
|
dev_dbg(fe->dvb->device, "%s: properties.props = %p\n", __func__, tvps->props);
|
2008-09-12 12:34:28 +08:00
|
|
|
|
|
|
|
/* Put an arbitrary limit on the number of messages that can
|
|
|
|
* be sent at once */
|
2008-10-07 09:46:08 +08:00
|
|
|
if ((tvps->num == 0) || (tvps->num > DTV_IOCTL_MAX_MSGS))
|
2008-09-12 12:34:28 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2010-01-16 21:25:38 +08:00
|
|
|
tvp = kmalloc(tvps->num * sizeof(struct dtv_property), GFP_KERNEL);
|
2008-09-12 12:34:28 +08:00
|
|
|
if (!tvp) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2014-09-24 21:15:22 +08:00
|
|
|
if (copy_from_user(tvp, (void __user *)tvps->props,
|
|
|
|
tvps->num * sizeof(struct dtv_property))) {
|
2008-09-12 12:34:28 +08:00
|
|
|
err = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2011-12-23 01:47:48 +08:00
|
|
|
/*
|
|
|
|
* Fills the cache out struct with the cache contents, plus
|
[media] dvb_frontend: Don't call get_frontend() if idle
If the frontend is in idle state, don't call get_frontend.
Calling get_frontend() when the device is not tuned may
result in wrong parameters to be returned to the
userspace.
I was tempted to not call get_frontend() at all, except
inside the dvb frontend thread, but this won't work for
all cases. The ISDB-T specs (ABNT NBR 15601 and ARIB
STD-B31) allow the broadcaster to dynamically change the
channel specs at runtime. That means that an ISDB-T optimized
application may want/need to monitor the TMCC tables, decoded
at the frontends via get_frontend call.
So, let's do the simpler change here.
Eventually, the logic could be changed to work only if
the device is tuned and has lock, but, even so, the
lock is also standard-dependent. For ISDB-T, the right
lock to wait is that the demod has TMCC lock. So, drivers
may need to implement some logic to detect if the get_frontend
info was retrieved or not.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-18 02:20:37 +08:00
|
|
|
* the data retrieved from get_frontend, if the frontend
|
|
|
|
* is not idle. Otherwise, returns the cached content
|
2011-12-23 01:47:48 +08:00
|
|
|
*/
|
[media] dvb_frontend: Don't call get_frontend() if idle
If the frontend is in idle state, don't call get_frontend.
Calling get_frontend() when the device is not tuned may
result in wrong parameters to be returned to the
userspace.
I was tempted to not call get_frontend() at all, except
inside the dvb frontend thread, but this won't work for
all cases. The ISDB-T specs (ABNT NBR 15601 and ARIB
STD-B31) allow the broadcaster to dynamically change the
channel specs at runtime. That means that an ISDB-T optimized
application may want/need to monitor the TMCC tables, decoded
at the frontends via get_frontend call.
So, let's do the simpler change here.
Eventually, the logic could be changed to work only if
the device is tuned and has lock, but, even so, the
lock is also standard-dependent. For ISDB-T, the right
lock to wait is that the demod has TMCC lock. So, drivers
may need to implement some logic to detect if the get_frontend
info was retrieved or not.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-18 02:20:37 +08:00
|
|
|
if (fepriv->state != FESTATE_IDLE) {
|
|
|
|
err = dtv_get_frontend(fe, NULL);
|
|
|
|
if (err < 0)
|
|
|
|
goto out;
|
|
|
|
}
|
2008-09-26 11:16:25 +08:00
|
|
|
for (i = 0; i < tvps->num; i++) {
|
[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>
2011-12-30 22:30:21 +08:00
|
|
|
err = dtv_property_process_get(fe, c, tvp + i, file);
|
2011-05-09 07:03:34 +08:00
|
|
|
if (err < 0)
|
|
|
|
goto out;
|
|
|
|
(tvp + i)->result = err;
|
2008-09-26 11:16:25 +08:00
|
|
|
}
|
2008-09-12 12:34:28 +08:00
|
|
|
|
2014-09-24 21:15:22 +08:00
|
|
|
if (copy_to_user((void __user *)tvps->props, tvp,
|
|
|
|
tvps->num * sizeof(struct dtv_property))) {
|
2008-09-12 12:34:28 +08:00
|
|
|
err = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
} else
|
2013-02-15 23:39:31 +08:00
|
|
|
err = -EOPNOTSUPP;
|
2008-09-12 12:34:28 +08:00
|
|
|
|
2008-09-11 21:23:01 +08:00
|
|
|
out:
|
|
|
|
kfree(tvp);
|
2008-09-05 08:19:43 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
static int dtv_set_frontend(struct dvb_frontend *fe)
|
2012-01-02 03:11:12 +08:00
|
|
|
{
|
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
|
|
|
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
|
|
|
|
struct dvb_frontend_tune_settings fetunesettings;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
u32 rolloff = 0;
|
2012-01-02 03:11:12 +08:00
|
|
|
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
if (dvb_frontend_check_parameters(fe) < 0)
|
|
|
|
return -EINVAL;
|
2012-01-02 03:11:12 +08:00
|
|
|
|
2012-04-07 05:38:18 +08:00
|
|
|
/*
|
|
|
|
* Initialize output parameters to match the values given by
|
|
|
|
* the user. FE_SET_FRONTEND triggers an initial frontend event
|
|
|
|
* with status = 0, which copies output parameters to userspace.
|
|
|
|
*/
|
|
|
|
dtv_property_legacy_params_sync(fe, &fepriv->parameters_out);
|
|
|
|
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
/*
|
|
|
|
* Be sure that the bandwidth will be filled for all
|
|
|
|
* non-satellite systems, as tuners need to know what
|
|
|
|
* low pass/Nyquist half filter should be applied, in
|
|
|
|
* order to avoid inter-channel noise.
|
|
|
|
*
|
|
|
|
* ISDB-T and DVB-T/T2 already sets bandwidth.
|
|
|
|
* ATSC and DVB-C don't set, so, the core should fill it.
|
|
|
|
*
|
|
|
|
* On DVB-C Annex A and C, the bandwidth is a function of
|
|
|
|
* the roll-off and symbol rate. Annex B defines different
|
|
|
|
* roll-off factors depending on the modulation. Fortunately,
|
|
|
|
* Annex B is only used with 6MHz, so there's no need to
|
|
|
|
* calculate it.
|
|
|
|
*
|
|
|
|
* While not officially supported, a side effect of handling it at
|
|
|
|
* the cache level is that a program could retrieve the bandwidth
|
|
|
|
* via DTV_BANDWIDTH_HZ, which may be useful for test programs.
|
|
|
|
*/
|
|
|
|
switch (c->delivery_system) {
|
|
|
|
case SYS_ATSC:
|
|
|
|
case SYS_DVBC_ANNEX_B:
|
|
|
|
c->bandwidth_hz = 6000000;
|
|
|
|
break;
|
|
|
|
case SYS_DVBC_ANNEX_A:
|
|
|
|
rolloff = 115;
|
|
|
|
break;
|
|
|
|
case SYS_DVBC_ANNEX_C:
|
|
|
|
rolloff = 113;
|
|
|
|
break;
|
2014-08-22 23:30:17 +08:00
|
|
|
case SYS_DVBS:
|
|
|
|
case SYS_TURBO:
|
2014-10-31 21:19:39 +08:00
|
|
|
case SYS_ISDBS:
|
2014-08-22 23:30:17 +08:00
|
|
|
rolloff = 135;
|
|
|
|
break;
|
|
|
|
case SYS_DVBS2:
|
|
|
|
switch (c->rolloff) {
|
|
|
|
case ROLLOFF_20:
|
|
|
|
rolloff = 120;
|
|
|
|
break;
|
|
|
|
case ROLLOFF_25:
|
|
|
|
rolloff = 125;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
case ROLLOFF_35:
|
|
|
|
rolloff = 135;
|
|
|
|
}
|
|
|
|
break;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (rolloff)
|
2015-04-15 02:12:54 +08:00
|
|
|
c->bandwidth_hz = mult_frac(c->symbol_rate, rolloff, 100);
|
2012-01-02 03:11:12 +08:00
|
|
|
|
|
|
|
/* force auto frequency inversion if requested */
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
if (dvb_force_auto_inversion)
|
2012-01-02 03:11:12 +08:00
|
|
|
c->inversion = INVERSION_AUTO;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* without hierarchical coding code_rate_LP is irrelevant,
|
|
|
|
* so we tolerate the otherwise invalid FEC_NONE setting
|
|
|
|
*/
|
|
|
|
if (c->hierarchy == HIERARCHY_NONE && c->code_rate_LP == FEC_NONE)
|
|
|
|
c->code_rate_LP = FEC_AUTO;
|
2012-01-02 03:11:12 +08:00
|
|
|
|
|
|
|
/* get frontend-specific tuning settings */
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
memset(&fetunesettings, 0, sizeof(struct dvb_frontend_tune_settings));
|
2012-01-02 03:11:12 +08:00
|
|
|
if (fe->ops.get_tune_settings && (fe->ops.get_tune_settings(fe, &fetunesettings) == 0)) {
|
|
|
|
fepriv->min_delay = (fetunesettings.min_delay_ms * HZ) / 1000;
|
|
|
|
fepriv->max_drift = fetunesettings.max_drift;
|
|
|
|
fepriv->step_size = fetunesettings.step_size;
|
|
|
|
} else {
|
|
|
|
/* default values */
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
switch (c->delivery_system) {
|
2012-05-08 02:01:37 +08:00
|
|
|
case SYS_DVBS:
|
|
|
|
case SYS_DVBS2:
|
|
|
|
case SYS_ISDBS:
|
|
|
|
case SYS_TURBO:
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
case SYS_DVBC_ANNEX_A:
|
|
|
|
case SYS_DVBC_ANNEX_C:
|
|
|
|
fepriv->min_delay = HZ / 20;
|
2012-01-02 03:11:12 +08:00
|
|
|
fepriv->step_size = c->symbol_rate / 16000;
|
|
|
|
fepriv->max_drift = c->symbol_rate / 2000;
|
|
|
|
break;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
case SYS_DVBT:
|
|
|
|
case SYS_DVBT2:
|
|
|
|
case SYS_ISDBT:
|
2012-08-13 09:33:21 +08:00
|
|
|
case SYS_DTMB:
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
fepriv->min_delay = HZ / 20;
|
2012-01-02 03:11:12 +08:00
|
|
|
fepriv->step_size = fe->ops.info.frequency_stepsize * 2;
|
|
|
|
fepriv->max_drift = (fe->ops.info.frequency_stepsize * 2) + 1;
|
|
|
|
break;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
default:
|
|
|
|
/*
|
|
|
|
* FIXME: This sounds wrong! if freqency_stepsize is
|
|
|
|
* defined by the frontend, why not use it???
|
|
|
|
*/
|
|
|
|
fepriv->min_delay = HZ / 20;
|
|
|
|
fepriv->step_size = 0; /* no zigzag */
|
2012-01-02 03:11:12 +08:00
|
|
|
fepriv->max_drift = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (dvb_override_tune_delay > 0)
|
|
|
|
fepriv->min_delay = (dvb_override_tune_delay * HZ) / 1000;
|
|
|
|
|
|
|
|
fepriv->state = FESTATE_RETUNE;
|
|
|
|
|
|
|
|
/* Request the search algorithm to search */
|
|
|
|
fepriv->algo_status |= DVBFE_ALGO_SEARCH_AGAIN;
|
|
|
|
|
|
|
|
dvb_frontend_clear_events(fe);
|
|
|
|
dvb_frontend_add_event(fe, 0);
|
|
|
|
dvb_frontend_wakeup(fe);
|
|
|
|
fepriv->status = 0;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-04-27 06:24:00 +08:00
|
|
|
static int dvb_frontend_ioctl_legacy(struct file *file,
|
2008-09-05 08:19:43 +08:00
|
|
|
unsigned int cmd, void *parg)
|
|
|
|
{
|
|
|
|
struct dvb_device *dvbdev = file->private_data;
|
|
|
|
struct dvb_frontend *fe = dvbdev->priv;
|
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
|
2013-02-15 23:39:31 +08:00
|
|
|
int err = -EOPNOTSUPP;
|
2008-09-05 08:19:43 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
switch (cmd) {
|
|
|
|
case FE_GET_INFO: {
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_info* info = parg;
|
2012-01-05 22:28:20 +08:00
|
|
|
|
2006-05-14 16:01:31 +08:00
|
|
|
memcpy(info, &fe->ops.info, sizeof(struct dvb_frontend_info));
|
2010-05-06 20:30:25 +08:00
|
|
|
dvb_frontend_get_frequency_limits(fe, &info->frequency_min, &info->frequency_max);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
/*
|
|
|
|
* Associate the 4 delivery systems supported by DVBv3
|
|
|
|
* API with their DVBv5 counterpart. For the other standards,
|
|
|
|
* use the closest type, assuming that it would hopefully
|
|
|
|
* work with a DVBv3 application.
|
|
|
|
* It should be noticed that, on multi-frontend devices with
|
|
|
|
* different types (terrestrial and cable, for example),
|
|
|
|
* a pure DVBv3 application won't be able to use all delivery
|
|
|
|
* systems. Yet, changing the DVBv5 cache to the other delivery
|
|
|
|
* system should be enough for making it work.
|
|
|
|
*/
|
|
|
|
switch (dvbv3_type(c->delivery_system)) {
|
|
|
|
case DVBV3_QPSK:
|
2012-01-05 22:28:20 +08:00
|
|
|
info->type = FE_QPSK;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
break;
|
|
|
|
case DVBV3_ATSC:
|
2012-01-05 22:28:20 +08:00
|
|
|
info->type = FE_ATSC;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
break;
|
|
|
|
case DVBV3_QAM:
|
2012-01-05 22:28:20 +08:00
|
|
|
info->type = FE_QAM;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
break;
|
|
|
|
case DVBV3_OFDM:
|
2012-01-05 22:28:20 +08:00
|
|
|
info->type = FE_OFDM;
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
break;
|
|
|
|
default:
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_err(fe->dvb->device,
|
|
|
|
"%s: doesn't know how to handle a DVBv3 call to delivery system %i\n",
|
|
|
|
__func__, c->delivery_system);
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
fe->ops.info.type = FE_OFDM;
|
|
|
|
}
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s: current delivery system on cache: %d, V3 type: %d\n",
|
|
|
|
__func__, c->delivery_system, fe->ops.info.type);
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
|
2015-08-31 17:13:45 +08:00
|
|
|
/* Set CAN_INVERSION_AUTO bit on in other than oneshot mode */
|
|
|
|
if (!(fepriv->tune_mode_flags & FE_TUNE_MODE_ONESHOT))
|
|
|
|
info->caps |= FE_CAN_INVERSION_AUTO;
|
2005-04-17 06:20:36 +08:00
|
|
|
err = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2005-07-08 08:57:36 +08:00
|
|
|
case FE_READ_STATUS: {
|
2015-06-08 01:53:52 +08:00
|
|
|
enum fe_status *status = parg;
|
2005-07-08 08:57:36 +08:00
|
|
|
|
2011-03-31 09:57:33 +08:00
|
|
|
/* if retune was requested but hasn't occurred yet, prevent
|
2005-07-08 08:57:36 +08:00
|
|
|
* that user get signal state from previous tuning */
|
2009-09-02 06:23:09 +08:00
|
|
|
if (fepriv->state == FESTATE_RETUNE ||
|
|
|
|
fepriv->state == FESTATE_ERROR) {
|
2005-07-08 08:57:36 +08:00
|
|
|
err=0;
|
|
|
|
*status = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.read_status)
|
|
|
|
err = fe->ops.read_status(fe, status);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
2005-07-08 08:57:36 +08:00
|
|
|
}
|
2012-08-10 06:00:51 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
case FE_READ_BER:
|
2012-08-10 06:00:51 +08:00
|
|
|
if (fe->ops.read_ber) {
|
|
|
|
if (fepriv->thread)
|
|
|
|
err = fe->ops.read_ber(fe, (__u32 *) parg);
|
|
|
|
else
|
|
|
|
err = -EAGAIN;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case FE_READ_SIGNAL_STRENGTH:
|
2012-08-10 06:00:51 +08:00
|
|
|
if (fe->ops.read_signal_strength) {
|
|
|
|
if (fepriv->thread)
|
|
|
|
err = fe->ops.read_signal_strength(fe, (__u16 *) parg);
|
|
|
|
else
|
|
|
|
err = -EAGAIN;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case FE_READ_SNR:
|
2012-08-10 06:00:51 +08:00
|
|
|
if (fe->ops.read_snr) {
|
|
|
|
if (fepriv->thread)
|
|
|
|
err = fe->ops.read_snr(fe, (__u16 *) parg);
|
|
|
|
else
|
|
|
|
err = -EAGAIN;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case FE_READ_UNCORRECTED_BLOCKS:
|
2012-08-10 06:00:51 +08:00
|
|
|
if (fe->ops.read_ucblocks) {
|
|
|
|
if (fepriv->thread)
|
|
|
|
err = fe->ops.read_ucblocks(fe, (__u32 *) parg);
|
|
|
|
else
|
|
|
|
err = -EAGAIN;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case FE_DISEQC_RESET_OVERLOAD:
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.diseqc_reset_overload) {
|
|
|
|
err = fe->ops.diseqc_reset_overload(fe);
|
2005-04-17 06:20:36 +08:00
|
|
|
fepriv->state = FESTATE_DISEQC;
|
|
|
|
fepriv->status = 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case FE_DISEQC_SEND_MASTER_CMD:
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.diseqc_send_master_cmd) {
|
2015-06-07 00:55:22 +08:00
|
|
|
struct dvb_diseqc_master_cmd *cmd = parg;
|
|
|
|
|
|
|
|
if (cmd->msg_len > sizeof(cmd->msg)) {
|
|
|
|
err = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
err = fe->ops.diseqc_send_master_cmd(fe, cmd);
|
2005-04-17 06:20:36 +08:00
|
|
|
fepriv->state = FESTATE_DISEQC;
|
|
|
|
fepriv->status = 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case FE_DISEQC_SEND_BURST:
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.diseqc_send_burst) {
|
2015-06-08 01:53:52 +08:00
|
|
|
err = fe->ops.diseqc_send_burst(fe,
|
|
|
|
(enum fe_sec_mini_cmd)parg);
|
2005-04-17 06:20:36 +08:00
|
|
|
fepriv->state = FESTATE_DISEQC;
|
|
|
|
fepriv->status = 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case FE_SET_TONE:
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.set_tone) {
|
2015-06-08 01:53:52 +08:00
|
|
|
err = fe->ops.set_tone(fe,
|
|
|
|
(enum fe_sec_tone_mode)parg);
|
|
|
|
fepriv->tone = (enum fe_sec_tone_mode)parg;
|
2005-04-17 06:20:36 +08:00
|
|
|
fepriv->state = FESTATE_DISEQC;
|
|
|
|
fepriv->status = 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case FE_SET_VOLTAGE:
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.set_voltage) {
|
2015-06-08 01:53:52 +08:00
|
|
|
err = fe->ops.set_voltage(fe,
|
|
|
|
(enum fe_sec_voltage)parg);
|
|
|
|
fepriv->voltage = (enum fe_sec_voltage)parg;
|
2005-04-17 06:20:36 +08:00
|
|
|
fepriv->state = FESTATE_DISEQC;
|
|
|
|
fepriv->status = 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case FE_DISHNETWORK_SEND_LEGACY_CMD:
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.dishnetwork_send_legacy_command) {
|
2015-06-08 01:53:52 +08:00
|
|
|
err = fe->ops.dishnetwork_send_legacy_command(fe,
|
|
|
|
(unsigned long)parg);
|
2005-04-17 06:20:36 +08:00
|
|
|
fepriv->state = FESTATE_DISEQC;
|
|
|
|
fepriv->status = 0;
|
2006-05-14 16:01:31 +08:00
|
|
|
} else if (fe->ops.set_voltage) {
|
2005-11-09 13:35:27 +08:00
|
|
|
/*
|
|
|
|
* NOTE: This is a fallback condition. Some frontends
|
|
|
|
* (stv0299 for instance) take longer than 8msec to
|
|
|
|
* respond to a set_voltage command. Those switches
|
|
|
|
* need custom routines to switch properly. For all
|
2010-05-06 20:30:25 +08:00
|
|
|
* other frontends, the following should work ok.
|
2005-11-09 13:35:27 +08:00
|
|
|
* Dish network legacy switches (as used by Dish500)
|
|
|
|
* are controlled by sending 9-bit command words
|
|
|
|
* spaced 8msec apart.
|
2011-03-31 09:57:33 +08:00
|
|
|
* the actual command word is switch/port dependent
|
2005-11-09 13:35:27 +08:00
|
|
|
* so it is up to the userspace application to send
|
|
|
|
* the right command.
|
|
|
|
* The command must always start with a '0' after
|
|
|
|
* initialization, so parg is 8 bits and does not
|
|
|
|
* include the initialization or start bit
|
|
|
|
*/
|
2008-09-04 04:11:54 +08:00
|
|
|
unsigned long swcmd = ((unsigned long) parg) << 1;
|
2015-05-31 15:17:06 +08:00
|
|
|
ktime_t nexttime;
|
|
|
|
ktime_t tv[10];
|
2005-11-09 13:35:27 +08:00
|
|
|
int i;
|
|
|
|
u8 last = 1;
|
|
|
|
if (dvb_frontend_debug)
|
2008-09-04 04:11:54 +08:00
|
|
|
printk("%s switch command: 0x%04lx\n", __func__, swcmd);
|
2015-05-31 15:17:06 +08:00
|
|
|
nexttime = ktime_get_real();
|
2005-11-09 13:35:27 +08:00
|
|
|
if (dvb_frontend_debug)
|
2012-10-24 02:57:23 +08:00
|
|
|
tv[0] = nexttime;
|
2005-11-09 13:35:27 +08:00
|
|
|
/* before sending a command, initialize by sending
|
|
|
|
* a 32ms 18V to the switch
|
|
|
|
*/
|
2006-05-14 16:01:31 +08:00
|
|
|
fe->ops.set_voltage(fe, SEC_VOLTAGE_18);
|
2005-11-09 13:35:27 +08:00
|
|
|
dvb_frontend_sleep_until(&nexttime, 32000);
|
|
|
|
|
|
|
|
for (i = 0; i < 9; i++) {
|
|
|
|
if (dvb_frontend_debug)
|
2015-05-31 15:17:06 +08:00
|
|
|
tv[i+1] = ktime_get_real();
|
2008-09-04 04:11:54 +08:00
|
|
|
if ((swcmd & 0x01) != last) {
|
2005-11-09 13:35:27 +08:00
|
|
|
/* set voltage to (last ? 13V : 18V) */
|
2006-05-14 16:01:31 +08:00
|
|
|
fe->ops.set_voltage(fe, (last) ? SEC_VOLTAGE_13 : SEC_VOLTAGE_18);
|
2005-11-09 13:35:27 +08:00
|
|
|
last = (last) ? 0 : 1;
|
|
|
|
}
|
2008-09-04 04:11:54 +08:00
|
|
|
swcmd = swcmd >> 1;
|
2005-11-09 13:35:27 +08:00
|
|
|
if (i != 8)
|
|
|
|
dvb_frontend_sleep_until(&nexttime, 8000);
|
|
|
|
}
|
|
|
|
if (dvb_frontend_debug) {
|
|
|
|
printk("%s(%d): switch delay (should be 32k followed by all 8k\n",
|
2008-04-09 10:20:00 +08:00
|
|
|
__func__, fe->dvb->num);
|
2005-11-09 13:35:27 +08:00
|
|
|
for (i = 1; i < 10; i++)
|
2015-05-31 15:17:06 +08:00
|
|
|
printk("%d: %d\n", i,
|
|
|
|
(int) ktime_us_delta(tv[i], tv[i-1]));
|
2005-11-09 13:35:27 +08:00
|
|
|
}
|
|
|
|
err = 0;
|
|
|
|
fepriv->state = FESTATE_DISEQC;
|
|
|
|
fepriv->status = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case FE_DISEQC_RECV_SLAVE_REPLY:
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.diseqc_recv_slave_reply)
|
|
|
|
err = fe->ops.diseqc_recv_slave_reply(fe, (struct dvb_diseqc_slave_reply*) parg);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case FE_ENABLE_HIGH_LNB_VOLTAGE:
|
2006-05-14 16:01:31 +08:00
|
|
|
if (fe->ops.enable_high_lnb_voltage)
|
|
|
|
err = fe->ops.enable_high_lnb_voltage(fe, (long) parg);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
|
2012-01-02 03:11:12 +08:00
|
|
|
case FE_SET_FRONTEND:
|
2013-03-19 02:25:36 +08:00
|
|
|
err = dvbv3_set_delivery_system(fe);
|
2012-01-02 03:11:14 +08:00
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
|
2012-01-02 03:11:16 +08:00
|
|
|
err = dtv_property_cache_sync(fe, c, parg);
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
err = dtv_set_frontend(fe);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
case FE_GET_EVENT:
|
|
|
|
err = dvb_frontend_get_event (fe, parg, file->f_flags);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case FE_GET_FRONTEND:
|
2012-01-02 03:11:16 +08:00
|
|
|
err = dtv_get_frontend(fe, parg);
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
2006-01-10 01:25:07 +08:00
|
|
|
|
|
|
|
case FE_SET_FRONTEND_TUNE_MODE:
|
2006-01-10 01:25:28 +08:00
|
|
|
fepriv->tune_mode_flags = (unsigned long) parg;
|
2006-06-30 00:16:04 +08:00
|
|
|
err = 0;
|
2006-01-10 01:25:07 +08:00
|
|
|
break;
|
2012-09-28 16:37:22 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
V4L/DVB (8985): S2API: Added dvb frontend changes to support a newer tuning API
This is an experimental patch to add a new tuning mechanism for
dvb frontends. Rather than passing fixed structures across the
user/kernel boundary, which need to be revised for each new modulation
type (or feature the kernel developers want to add), this implements
a simpler message based approach, allowing fe commands to be broken
down into a series of small fixed size transactions, presented
in an array.
The goal is to avoid changing the user/kernel ABI in the future, by
simply creating new frontend commands (and sequencies of commands) that
help us add support for brand new demodulator, delivery system or
statistics related commmands.
known issues:
checkpatch voilations
feedback from various developers yet to be implemented, relating
to namespace conventions, variable length array passing conventions,
and generally some optimization.
This patch should support all existing tuning mechanisms through the
new API, as well as adding 8PSK, DVB-S2 NBC-QPSK and ISDB-T API support.
For testing and exercise purposes, see the latest tune.c tool
available from http://www.steventoth.net/linux/s2
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2008-09-04 12:12:25 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static unsigned int dvb_frontend_poll(struct file *file, struct poll_table_struct *wait)
|
|
|
|
{
|
|
|
|
struct dvb_device *dvbdev = file->private_data;
|
|
|
|
struct dvb_frontend *fe = dvbdev->priv;
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg_ratelimited(fe->dvb->device, "%s:\n", __func__);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
poll_wait (file, &fepriv->events.wait_queue, wait);
|
|
|
|
|
|
|
|
if (fepriv->events.eventw != fepriv->events.eventr)
|
|
|
|
return (POLLIN | POLLRDNORM | POLLPRI);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dvb_frontend_open(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
struct dvb_device *dvbdev = file->private_data;
|
|
|
|
struct dvb_frontend *fe = dvbdev->priv;
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2008-10-11 22:44:05 +08:00
|
|
|
struct dvb_adapter *adapter = fe->dvb;
|
2005-04-17 06:20:36 +08:00
|
|
|
int ret;
|
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s:\n", __func__);
|
2014-07-13 00:44:12 +08:00
|
|
|
if (fe->exit == DVB_FE_DEVICE_REMOVED)
|
2010-05-06 02:59:20 +08:00
|
|
|
return -ENODEV;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-10-11 22:44:05 +08:00
|
|
|
if (adapter->mfe_shared) {
|
|
|
|
mutex_lock (&adapter->mfe_lock);
|
2008-10-16 00:37:59 +08:00
|
|
|
|
|
|
|
if (adapter->mfe_dvbdev == NULL)
|
|
|
|
adapter->mfe_dvbdev = dvbdev;
|
|
|
|
|
|
|
|
else if (adapter->mfe_dvbdev != dvbdev) {
|
|
|
|
struct dvb_device
|
|
|
|
*mfedev = adapter->mfe_dvbdev;
|
|
|
|
struct dvb_frontend
|
|
|
|
*mfe = mfedev->priv;
|
|
|
|
struct dvb_frontend_private
|
|
|
|
*mfepriv = mfe->frontend_priv;
|
|
|
|
int mferetry = (dvb_mfe_wait_time << 1);
|
|
|
|
|
|
|
|
mutex_unlock (&adapter->mfe_lock);
|
|
|
|
while (mferetry-- && (mfedev->users != -1 ||
|
|
|
|
mfepriv->thread != NULL)) {
|
|
|
|
if(msleep_interruptible(500)) {
|
|
|
|
if(signal_pending(current))
|
|
|
|
return -EINTR;
|
2008-10-11 22:44:05 +08:00
|
|
|
}
|
2008-10-16 00:37:59 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
mutex_lock (&adapter->mfe_lock);
|
|
|
|
if(adapter->mfe_dvbdev != dvbdev) {
|
2008-10-11 22:44:05 +08:00
|
|
|
mfedev = adapter->mfe_dvbdev;
|
|
|
|
mfe = mfedev->priv;
|
|
|
|
mfepriv = mfe->frontend_priv;
|
2008-10-16 00:37:59 +08:00
|
|
|
if (mfedev->users != -1 ||
|
|
|
|
mfepriv->thread != NULL) {
|
|
|
|
mutex_unlock (&adapter->mfe_lock);
|
|
|
|
return -EBUSY;
|
2008-10-11 22:44:05 +08:00
|
|
|
}
|
2008-10-16 00:37:59 +08:00
|
|
|
adapter->mfe_dvbdev = dvbdev;
|
2008-10-11 22:44:05 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-08-25 23:00:23 +08:00
|
|
|
if (dvbdev->users == -1 && fe->ops.ts_bus_ctrl) {
|
|
|
|
if ((ret = fe->ops.ts_bus_ctrl(fe, 1)) < 0)
|
2008-10-11 22:44:05 +08:00
|
|
|
goto err0;
|
[media] dvb_frontend: fix race condition in stopping/starting frontend
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: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Jon Sayers <j.sayers@hauppauge.co.uk>
Cc: Florent Audebert <florent.audebert@anevia.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-05 08:55:01 +08:00
|
|
|
|
|
|
|
/* If we took control of the bus, we need to force
|
|
|
|
reinitialization. This is because many ts_bus_ctrl()
|
|
|
|
functions strobe the RESET pin on the demod, and if the
|
|
|
|
frontend thread already exists then the dvb_init() routine
|
|
|
|
won't get called (which is what usually does initial
|
|
|
|
register configuration). */
|
|
|
|
fepriv->reinitialise = 1;
|
2006-09-25 23:41:53 +08:00
|
|
|
}
|
|
|
|
|
2007-08-25 23:00:23 +08:00
|
|
|
if ((ret = dvb_generic_open (inode, file)) < 0)
|
|
|
|
goto err1;
|
2006-07-10 14:34:14 +08:00
|
|
|
|
2007-08-25 23:00:23 +08:00
|
|
|
if ((file->f_flags & O_ACCMODE) != O_RDONLY) {
|
2006-07-10 14:34:14 +08:00
|
|
|
/* normal tune mode when opened R/W */
|
|
|
|
fepriv->tune_mode_flags &= ~FE_TUNE_MODE_ONESHOT;
|
|
|
|
fepriv->tone = -1;
|
|
|
|
fepriv->voltage = -1;
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
ret = dvb_frontend_start (fe);
|
|
|
|
if (ret)
|
2007-08-25 23:00:23 +08:00
|
|
|
goto err2;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* empty event queue */
|
|
|
|
fepriv->events.eventr = fepriv->events.eventw = 0;
|
|
|
|
}
|
|
|
|
|
2008-10-11 22:44:05 +08:00
|
|
|
if (adapter->mfe_shared)
|
|
|
|
mutex_unlock (&adapter->mfe_lock);
|
2005-04-17 06:20:36 +08:00
|
|
|
return ret;
|
2007-08-25 23:00:23 +08:00
|
|
|
|
|
|
|
err2:
|
|
|
|
dvb_generic_release(inode, file);
|
|
|
|
err1:
|
|
|
|
if (dvbdev->users == -1 && fe->ops.ts_bus_ctrl)
|
|
|
|
fe->ops.ts_bus_ctrl(fe, 0);
|
2008-10-11 22:44:05 +08:00
|
|
|
err0:
|
|
|
|
if (adapter->mfe_shared)
|
|
|
|
mutex_unlock (&adapter->mfe_lock);
|
2007-08-25 23:00:23 +08:00
|
|
|
return ret;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int dvb_frontend_release(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
struct dvb_device *dvbdev = file->private_data;
|
|
|
|
struct dvb_frontend *fe = dvbdev->priv;
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2007-04-14 21:18:58 +08:00
|
|
|
int ret;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s:\n", __func__);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-12-10 08:37:00 +08:00
|
|
|
if ((file->f_flags & O_ACCMODE) != O_RDONLY) {
|
2005-04-17 06:20:36 +08:00
|
|
|
fepriv->release_jiffies = jiffies;
|
2011-12-10 08:37:00 +08:00
|
|
|
mb();
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-04-14 21:18:58 +08:00
|
|
|
ret = dvb_generic_release (inode, file);
|
|
|
|
|
2007-08-25 23:00:23 +08:00
|
|
|
if (dvbdev->users == -1) {
|
2011-12-10 08:37:00 +08:00
|
|
|
wake_up(&fepriv->wait_queue);
|
2014-07-13 00:44:12 +08:00
|
|
|
if (fe->exit != DVB_FE_NO_EXIT)
|
2007-08-25 23:00:23 +08:00
|
|
|
wake_up(&dvbdev->wait_queue);
|
|
|
|
if (fe->ops.ts_bus_ctrl)
|
|
|
|
fe->ops.ts_bus_ctrl(fe, 0);
|
2007-04-14 21:18:58 +08:00
|
|
|
}
|
2007-08-25 23:00:23 +08:00
|
|
|
|
2007-04-14 21:18:58 +08:00
|
|
|
return ret;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2009-01-11 17:12:43 +08:00
|
|
|
static const struct file_operations dvb_frontend_fops = {
|
2005-04-17 06:20:36 +08:00
|
|
|
.owner = THIS_MODULE,
|
2010-04-27 06:24:00 +08:00
|
|
|
.unlocked_ioctl = dvb_generic_ioctl,
|
2005-04-17 06:20:36 +08:00
|
|
|
.poll = dvb_frontend_poll,
|
|
|
|
.open = dvb_frontend_open,
|
llseek: automatically add .llseek fop
All file_operations should get a .llseek operation so we can make
nonseekable_open the default for future file operations without a
.llseek pointer.
The three cases that we can automatically detect are no_llseek, seq_lseek
and default_llseek. For cases where we can we can automatically prove that
the file offset is always ignored, we use noop_llseek, which maintains
the current behavior of not returning an error from a seek.
New drivers should normally not use noop_llseek but instead use no_llseek
and call nonseekable_open at open time. Existing drivers can be converted
to do the same when the maintainer knows for certain that no user code
relies on calling seek on the device file.
The generated code is often incorrectly indented and right now contains
comments that clarify for each added line why a specific variant was
chosen. In the version that gets submitted upstream, the comments will
be gone and I will manually fix the indentation, because there does not
seem to be a way to do that using coccinelle.
Some amount of new code is currently sitting in linux-next that should get
the same modifications, which I will do at the end of the merge window.
Many thanks to Julia Lawall for helping me learn to write a semantic
patch that does all this.
===== begin semantic patch =====
// This adds an llseek= method to all file operations,
// as a preparation for making no_llseek the default.
//
// The rules are
// - use no_llseek explicitly if we do nonseekable_open
// - use seq_lseek for sequential files
// - use default_llseek if we know we access f_pos
// - use noop_llseek if we know we don't access f_pos,
// but we still want to allow users to call lseek
//
@ open1 exists @
identifier nested_open;
@@
nested_open(...)
{
<+...
nonseekable_open(...)
...+>
}
@ open exists@
identifier open_f;
identifier i, f;
identifier open1.nested_open;
@@
int open_f(struct inode *i, struct file *f)
{
<+...
(
nonseekable_open(...)
|
nested_open(...)
)
...+>
}
@ read disable optional_qualifier exists @
identifier read_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
expression E;
identifier func;
@@
ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
{
<+...
(
*off = E
|
*off += E
|
func(..., off, ...)
|
E = *off
)
...+>
}
@ read_no_fpos disable optional_qualifier exists @
identifier read_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
@@
ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
{
... when != off
}
@ write @
identifier write_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
expression E;
identifier func;
@@
ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
{
<+...
(
*off = E
|
*off += E
|
func(..., off, ...)
|
E = *off
)
...+>
}
@ write_no_fpos @
identifier write_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
@@
ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
{
... when != off
}
@ fops0 @
identifier fops;
@@
struct file_operations fops = {
...
};
@ has_llseek depends on fops0 @
identifier fops0.fops;
identifier llseek_f;
@@
struct file_operations fops = {
...
.llseek = llseek_f,
...
};
@ has_read depends on fops0 @
identifier fops0.fops;
identifier read_f;
@@
struct file_operations fops = {
...
.read = read_f,
...
};
@ has_write depends on fops0 @
identifier fops0.fops;
identifier write_f;
@@
struct file_operations fops = {
...
.write = write_f,
...
};
@ has_open depends on fops0 @
identifier fops0.fops;
identifier open_f;
@@
struct file_operations fops = {
...
.open = open_f,
...
};
// use no_llseek if we call nonseekable_open
////////////////////////////////////////////
@ nonseekable1 depends on !has_llseek && has_open @
identifier fops0.fops;
identifier nso ~= "nonseekable_open";
@@
struct file_operations fops = {
... .open = nso, ...
+.llseek = no_llseek, /* nonseekable */
};
@ nonseekable2 depends on !has_llseek @
identifier fops0.fops;
identifier open.open_f;
@@
struct file_operations fops = {
... .open = open_f, ...
+.llseek = no_llseek, /* open uses nonseekable */
};
// use seq_lseek for sequential files
/////////////////////////////////////
@ seq depends on !has_llseek @
identifier fops0.fops;
identifier sr ~= "seq_read";
@@
struct file_operations fops = {
... .read = sr, ...
+.llseek = seq_lseek, /* we have seq_read */
};
// use default_llseek if there is a readdir
///////////////////////////////////////////
@ fops1 depends on !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier readdir_e;
@@
// any other fop is used that changes pos
struct file_operations fops = {
... .readdir = readdir_e, ...
+.llseek = default_llseek, /* readdir is present */
};
// use default_llseek if at least one of read/write touches f_pos
/////////////////////////////////////////////////////////////////
@ fops2 depends on !fops1 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read.read_f;
@@
// read fops use offset
struct file_operations fops = {
... .read = read_f, ...
+.llseek = default_llseek, /* read accesses f_pos */
};
@ fops3 depends on !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier write.write_f;
@@
// write fops use offset
struct file_operations fops = {
... .write = write_f, ...
+ .llseek = default_llseek, /* write accesses f_pos */
};
// Use noop_llseek if neither read nor write accesses f_pos
///////////////////////////////////////////////////////////
@ fops4 depends on !fops1 && !fops2 && !fops3 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read_no_fpos.read_f;
identifier write_no_fpos.write_f;
@@
// write fops use offset
struct file_operations fops = {
...
.write = write_f,
.read = read_f,
...
+.llseek = noop_llseek, /* read and write both use no f_pos */
};
@ depends on has_write && !has_read && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier write_no_fpos.write_f;
@@
struct file_operations fops = {
... .write = write_f, ...
+.llseek = noop_llseek, /* write uses no f_pos */
};
@ depends on has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read_no_fpos.read_f;
@@
struct file_operations fops = {
... .read = read_f, ...
+.llseek = noop_llseek, /* read uses no f_pos */
};
@ depends on !has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
@@
struct file_operations fops = {
...
+.llseek = noop_llseek, /* no read or write fn */
};
===== End semantic patch =====
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Julia Lawall <julia@diku.dk>
Cc: Christoph Hellwig <hch@infradead.org>
2010-08-16 00:52:59 +08:00
|
|
|
.release = dvb_frontend_release,
|
|
|
|
.llseek = noop_llseek,
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2012-08-15 09:21:06 +08:00
|
|
|
int dvb_frontend_suspend(struct dvb_frontend *fe)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
dev_dbg(fe->dvb->device, "%s: adap=%d fe=%d\n", __func__, fe->dvb->num,
|
|
|
|
fe->id);
|
|
|
|
|
2014-08-10 08:47:19 +08:00
|
|
|
if (fe->ops.tuner_ops.suspend)
|
|
|
|
ret = fe->ops.tuner_ops.suspend(fe);
|
|
|
|
else if (fe->ops.tuner_ops.sleep)
|
2012-08-15 09:21:06 +08:00
|
|
|
ret = fe->ops.tuner_ops.sleep(fe);
|
|
|
|
|
|
|
|
if (fe->ops.sleep)
|
|
|
|
ret = fe->ops.sleep(fe);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dvb_frontend_suspend);
|
|
|
|
|
|
|
|
int dvb_frontend_resume(struct dvb_frontend *fe)
|
|
|
|
{
|
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
dev_dbg(fe->dvb->device, "%s: adap=%d fe=%d\n", __func__, fe->dvb->num,
|
|
|
|
fe->id);
|
|
|
|
|
2014-07-25 00:02:14 +08:00
|
|
|
fe->exit = DVB_FE_DEVICE_RESUME;
|
2012-08-15 09:21:06 +08:00
|
|
|
if (fe->ops.init)
|
|
|
|
ret = fe->ops.init(fe);
|
|
|
|
|
2014-08-10 08:47:19 +08:00
|
|
|
if (fe->ops.tuner_ops.resume)
|
|
|
|
ret = fe->ops.tuner_ops.resume(fe);
|
|
|
|
else if (fe->ops.tuner_ops.init)
|
2012-08-15 09:21:06 +08:00
|
|
|
ret = fe->ops.tuner_ops.init(fe);
|
|
|
|
|
2015-11-10 21:50:30 +08:00
|
|
|
if (fe->ops.set_tone && fepriv->tone != -1)
|
|
|
|
fe->ops.set_tone(fe, fepriv->tone);
|
|
|
|
if (fe->ops.set_voltage && fepriv->voltage != -1)
|
|
|
|
fe->ops.set_voltage(fe, fepriv->voltage);
|
|
|
|
|
2014-07-25 00:02:14 +08:00
|
|
|
fe->exit = DVB_FE_NO_EXIT;
|
2012-08-15 09:21:06 +08:00
|
|
|
fepriv->state = FESTATE_RETUNE;
|
|
|
|
dvb_frontend_wakeup(fe);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dvb_frontend_resume);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
int dvb_register_frontend(struct dvb_adapter* dvb,
|
|
|
|
struct dvb_frontend* fe)
|
|
|
|
{
|
|
|
|
struct dvb_frontend_private *fepriv;
|
2015-01-02 22:00:17 +08:00
|
|
|
const struct dvb_device dvbdev_template = {
|
2005-04-17 06:20:36 +08:00
|
|
|
.users = ~0,
|
|
|
|
.writers = 1,
|
|
|
|
.readers = (~0)-1,
|
|
|
|
.fops = &dvb_frontend_fops,
|
2015-01-02 22:00:17 +08:00
|
|
|
#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
|
|
|
|
.name = fe->ops.info.name,
|
|
|
|
#endif
|
2005-04-17 06:20:36 +08:00
|
|
|
.kernel_ioctl = dvb_frontend_ioctl
|
|
|
|
};
|
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(dvb->device, "%s:\n", __func__);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-02-07 16:49:14 +08:00
|
|
|
if (mutex_lock_interruptible(&frontend_mutex))
|
2005-04-17 06:20:36 +08:00
|
|
|
return -ERESTARTSYS;
|
|
|
|
|
2006-01-12 05:40:56 +08:00
|
|
|
fe->frontend_priv = kzalloc(sizeof(struct dvb_frontend_private), GFP_KERNEL);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (fe->frontend_priv == NULL) {
|
2006-02-07 16:49:14 +08:00
|
|
|
mutex_unlock(&frontend_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2005-05-17 12:54:24 +08:00
|
|
|
fepriv = fe->frontend_priv;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-09-07 22:33:27 +08:00
|
|
|
sema_init(&fepriv->sem, 1);
|
2005-04-17 06:20:36 +08:00
|
|
|
init_waitqueue_head (&fepriv->wait_queue);
|
|
|
|
init_waitqueue_head (&fepriv->events.wait_queue);
|
2007-07-31 01:58:10 +08:00
|
|
|
mutex_init(&fepriv->events.mtx);
|
2005-04-17 06:20:36 +08:00
|
|
|
fe->dvb = dvb;
|
|
|
|
fepriv->inversion = INVERSION_OFF;
|
|
|
|
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_info(fe->dvb->device,
|
|
|
|
"DVB: registering adapter %i frontend %i (%s)...\n",
|
|
|
|
fe->dvb->num, fe->id, fe->ops.info.name);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
dvb_register_device (fe->dvb, &fepriv->dvbdev, &dvbdev_template,
|
2015-08-22 03:18:18 +08:00
|
|
|
fe, DVB_DEVICE_FRONTEND, 0);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
/*
|
|
|
|
* Initialize the cache to the proper values according with the
|
|
|
|
* first supported delivery system (ops->delsys[0])
|
|
|
|
*/
|
2012-01-11 05:00:50 +08:00
|
|
|
|
2013-03-19 02:25:36 +08:00
|
|
|
fe->dtv_property_cache.delivery_system = fe->ops.delsys[0];
|
[media] dvb_frontend: Don't use ops->info.type anymore
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: Mauro Carvalho Chehab <mchehab@redhat.com>
2012-01-02 03:11:13 +08:00
|
|
|
dvb_frontend_clear_cache(fe);
|
|
|
|
|
2006-02-07 16:49:14 +08:00
|
|
|
mutex_unlock(&frontend_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dvb_register_frontend);
|
|
|
|
|
|
|
|
int dvb_unregister_frontend(struct dvb_frontend* fe)
|
|
|
|
{
|
2005-05-17 12:54:24 +08:00
|
|
|
struct dvb_frontend_private *fepriv = fe->frontend_priv;
|
2012-08-16 07:28:37 +08:00
|
|
|
dev_dbg(fe->dvb->device, "%s:\n", __func__);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-04-14 21:19:18 +08:00
|
|
|
mutex_lock(&frontend_mutex);
|
2007-04-14 21:18:58 +08:00
|
|
|
dvb_frontend_stop (fe);
|
2007-04-14 21:19:18 +08:00
|
|
|
mutex_unlock(&frontend_mutex);
|
|
|
|
|
|
|
|
if (fepriv->dvbdev->users < -1)
|
|
|
|
wait_event(fepriv->dvbdev->wait_queue,
|
|
|
|
fepriv->dvbdev->users==-1);
|
|
|
|
|
2006-02-07 16:49:14 +08:00
|
|
|
mutex_lock(&frontend_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
dvb_unregister_device (fepriv->dvbdev);
|
2006-08-08 20:10:08 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* fe is invalid now */
|
|
|
|
kfree(fepriv);
|
2006-02-07 16:49:14 +08:00
|
|
|
mutex_unlock(&frontend_mutex);
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dvb_unregister_frontend);
|
2006-08-08 20:10:09 +08:00
|
|
|
|
2008-04-30 08:38:46 +08:00
|
|
|
#ifdef CONFIG_MEDIA_ATTACH
|
2006-08-08 20:10:09 +08:00
|
|
|
void dvb_frontend_detach(struct dvb_frontend* fe)
|
|
|
|
{
|
|
|
|
void *ptr;
|
|
|
|
|
|
|
|
if (fe->ops.release_sec) {
|
|
|
|
fe->ops.release_sec(fe);
|
2014-05-29 20:20:13 +08:00
|
|
|
dvb_detach(fe->ops.release_sec);
|
2006-08-08 20:10:09 +08:00
|
|
|
}
|
|
|
|
if (fe->ops.tuner_ops.release) {
|
|
|
|
fe->ops.tuner_ops.release(fe);
|
2014-05-29 20:20:13 +08:00
|
|
|
dvb_detach(fe->ops.tuner_ops.release);
|
2006-08-08 20:10:09 +08:00
|
|
|
}
|
2007-12-21 22:34:45 +08:00
|
|
|
if (fe->ops.analog_ops.release) {
|
|
|
|
fe->ops.analog_ops.release(fe);
|
2014-05-29 20:20:13 +08:00
|
|
|
dvb_detach(fe->ops.analog_ops.release);
|
2007-12-21 22:34:45 +08:00
|
|
|
}
|
2006-08-08 20:10:09 +08:00
|
|
|
ptr = (void*)fe->ops.release;
|
|
|
|
if (ptr) {
|
|
|
|
fe->ops.release(fe);
|
2014-05-29 20:20:13 +08:00
|
|
|
dvb_detach(ptr);
|
2006-08-08 20:10:09 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
void dvb_frontend_detach(struct dvb_frontend* fe)
|
|
|
|
{
|
|
|
|
if (fe->ops.release_sec)
|
|
|
|
fe->ops.release_sec(fe);
|
|
|
|
if (fe->ops.tuner_ops.release)
|
|
|
|
fe->ops.tuner_ops.release(fe);
|
2007-12-21 22:34:45 +08:00
|
|
|
if (fe->ops.analog_ops.release)
|
|
|
|
fe->ops.analog_ops.release(fe);
|
2006-08-08 20:10:09 +08:00
|
|
|
if (fe->ops.release)
|
|
|
|
fe->ops.release(fe);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
EXPORT_SYMBOL(dvb_frontend_detach);
|