[media] dvb_frontend: Don't use ops->info.type anymore
authorMauro Carvalho Chehab <mchehab@redhat.com>
Sun, 1 Jan 2012 19:11:13 +0000 (16:11 -0300)
committerMauro Carvalho Chehab <mchehab@redhat.com>
Wed, 4 Jan 2012 19:29:36 +0000 (17:29 -0200)
commit5bfaaddef8d46ca274e8ff819311e1eef1554e74
treef7832ddc6333c20b8646db093c33668ab143d70d
parent9682cea27e9ce7ede8e5c608900a52edaeb57a6b
[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>
drivers/media/dvb/dvb-core/dvb_frontend.c