DVB new get info ioctl

[Mauro Carvalho Chehab <mchehab@osg.samsung.com>]

Hi Michael,

As you know, one of the topics discussed during the last Media Summit were about
writing a new ioctl to replace FE_GET_INFO's fe_caps. 

The summary of our discussions follow bellow:
(mental note: I should put the description below on our mini-summit notes): 

<SUMMIT>
The main issue with fe_caps is that, currently, there are only two bits left, 
between:
	FE_HAS_EXTENDED_CAPS		= 0x800000, 
and
	FE_CAN_MULTISTREAM		= 0x4000000,

And this is not enough to represent the current capabilities of
modern delivery system's frontends.

As a few examples of missing things that we want to be able to
report, we have:

- Some DVB-C2 demods supports automatic symbol rate detection between
  a certain range (Ralph);

- Some devices that only work on "auto" mode, sometimes being even
  unable to return what it was detected, even with the full specs (Ralph).

- Complex delivery systems like ISDB-T have some combinations that
  aren't very common, and some chipset providers decided to not implement
  (Mauro).
  For example, mb86a20s frontend doesn't support guard interval equal to
  1/32[1].

So, the agreeded strategy is to write a new ioctl that, once the delivery
system is set, it will return what are the valid values/ranges that
a given frontend property can support.

In order to optimize the drivers, the core could pre-fill it with all 
that it is supported by a given delivery system, letting the driver to
override it, disabling the features that aren't supported.

Michael proposed to send RFCs for that.
</SUMMIT>

[1] Also, while double checking today at the code, it also doesn't 
    support mode 1 (2K).

That's what it was agreed during the meeting.

After our discussions about a new ioctl that would be able to properly
report the frontend capabilities for new standards, during the Media Summit,
in order to be able to report the currently needs, I did some brainstorming
about that.

It come to me that the fe_caps replacement ioctl should need to 
return not only the valid values/ranges but also a flag that will
indicate if:

- The frontend supports auto-detecting the parameter (CAN_AUTO);
- The frontend allows setting such parameter (CAN_SET) [2];
- The frontend can report the detected parameter (CAN_GET);
- If the valid values comes on ranges (IS_RANGE), to be used by
  parameters like frequency and symbol rate.

Btw, we have a problem with IS_RANGE for symbol rate: There are actually
two ranges there:
	- The supported symbol rate range;
	- The auto-detected symbol rate range.

Perhaps Ralph could shed us a light on it, but my understanding is
that some devices might have a broader supported range than the
one that the frontend can auto-detect.

If so, the solution could be to add an extra property for the
"autodetection symbol rate" range.

[2] ISDB-S new Toshiba demod, for example, doesn't allow setting the
    modulation. This should always be auto-detected via TMCC table.
    Btw, this seems to be a requirement at the spec (but nothing
    prevents some vendor to not implement it).

We've discussed in priv that we might report everything as ranges,
but, on a second taught, I think that we should only use ranges for
numeric values, and not for enums.

Regards,
Mauro