user/sven/linux.git/include/linux/dvb, branch v3.4.40

[media] dvb: deprecate the usage of ops->info.type

2012-01-04T19:30:20Z

Mark info.type as deprecated inside the header, recommending the usage of DTV_ENUM_DELSYS DVBv5 command instead. Signed-off-by: Mauro Carvalho Chehab

[media] dvb-core: be sure that drivers won't use DVBv3 internally

2011-12-31T12:23:01Z

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

[media] Remove Annex A/C selection via roll-off factor

2011-12-20T13:50:23Z

Instead of using a roll-off factor, change DRX-K & friends to select the bandwidth filter and the Nyquist half roll-off via delivery system. This provides a cleaner support for Annex A/C switch. Signed-off-by: Mauro Carvalho Chehab

[media] DVB: Use a unique delivery system identifier for DVBC_ANNEX_C

2011-12-20T13:49:15Z

Use a unique delivery system identifier for DVBC_ANNEX_C, just like any other. DVBC_ANNEX_A and DVBC_ANNEX_C have slightly different parameters and are used in 2 geographically different locations. Signed-off-by: Manu Abraham Signed-off-by: Mauro Carvalho Chehab

[media] DVB: Query DVB frontend delivery capabilities

2011-12-12T17:03:32Z

Currently, for any multi-standard frontend it is assumed that it just has a single standard capability. This is fine in some cases, but makes things hard when there are incompatible standards in conjuction. Eg: DVB-S can be seen as a subset of DVB-S2, but the same doesn't hold the same for DSS. This is not specific to any driver as it is, but a generic issue. This was handled correctly in the multiproto tree, while such functionality is missing from the v5 API update. http://www.linuxtv.org/pipermail/vdr/2008-November/018417.html Later on a FE_CAN_2G_MODULATION was added as a hack to workaround this issue in the v5 API, but that hack is incapable of addressing the issue, as it can be used to simply distinguish between DVB-S and DVB-S2 alone, or another X vs X2 modulation. If there are more systems, then you have a potential issue. An application needs to query the device capabilities before requesting any operation from the device. Signed-off-by: Manu Abraham Acked-by: Andreas Oberritter Acked-by: Oliver Endriss Signed-off-by: Mauro Carvalho Chehab

[media] dvb: Allow select between DVB-C Annex A and Annex C

2011-11-11T14:46:23Z

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

[media] DVB: increment minor version after addition of SYS_TURBO

2011-09-03T22:07:21Z

Signed-off-by: Andreas Oberritter Signed-off-by: Mauro Carvalho Chehab

[media] DVB: Add SYS_TURBO for north american turbo code FEC

2011-09-03T21:07:14Z

Signed-off-by: Andreas Oberritter Signed-off-by: Mauro Carvalho Chehab

Revert "[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS"

2011-07-27T20:52:58Z

Based on those feedback: http://www.spinics.net/lists/linux-media/msg33704.html http://www.spinics.net/lists/linux-media/msg33700.html I'm reverting the removal of this unused ioctl, as it seems that some drivers under development may be using. So, I'll wait until the next merge window before removing those unused ioctls, to give a chance for developers to submit their pending work. This reverts commit db48923da6c528d461b5e764692239eb9c1b7a00. Cc: Andreas Oberritter Cc: Manu Abraham Signed-off-by: Mauro Carvalho Chehab

[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS

2011-07-27T20:52:56Z

While this ioctl is defined inside dvb/audio.h, it is not docummented at the API specs, nor implemented on any driver inside the Linux Kernel. So, it doesn't make sense to keep it here. As this is not used anywere, removing it is not a regression. So, there's no need to use the normal features-to-be-removed process. Signed-off-by: Mauro Carvalho Chehab