DVB core enhancements - comments please?

DVB core enhancements - comments please?

[Antti Palosaari]

Here is my list of needed DVB core related changes. Feel free to comment 
- what are not needed or what you would like to see instead. I will try 
to implement what I can (and what I like most interesting :).


general validly checking for demodulator callback input values
--------------------------------------------------
* currently each driver needs to validate those
* values are highly hooked up to used television standard
* we can do almost all validly checking inside core
* we can also check if call is possible to perform in given condition
* for example BER is not valid when demod is unlocked


suspend / resume support
--------------------------------------------------
* support is currently quite missing, all what is done is on interface 
drivers
* needs power management
* streaming makes it hard
* quite a lot work to get it working in case of straming is ongoing


use Kernel power management instead of own
--------------------------------------------------
* there seems to be Kernel services for power-management
* study if it is wise to use Kernel services instead of own
* own PM is still working very well, at least I dont know any problems


SDR - Softaware Defined Radio support DVB API
--------------------------------------------------
* 
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/44461
* there is existing devices that are SDR (RTL2832U "rtl-sdr")
* SDR is quite near what is digital TV streaming
* study what is needed
* new delivery system for frontend API called SDR?
* some core changes needed, like status (is locked etc)
* how about demuxer?
* stream conversion, inside Kernel?
* what are new parameters needed for DVB API?


DTMB standard support for DVB API
--------------------------------------------------
* it is Chinese DTV standard
* I already ran RFC but have been too busy for implementing it :]


LNA (low-noise amplifier) support for DVB API
--------------------------------------------------
* there is quite a lot of devices having LNA
* currently not supported => LNA is configured off typically


offer polling method for statistics
--------------------------------------------------
* many static counters could not be read as a "one go"
* typical cycle is : start measurement => wait => read counters
* some drivers starts own internal work-queue for polling (complexity)
* some drivers blocks IOCTL when taking measurement (bad)


fix frontend properties
--------------------------------------------------
* those has been broken since MFE => SFE change
* currently implemented as a properties per driver
* need to be properties per delivery system
* are broken because driver/chip could support multiple DTV standards

regards
Antti
-- 
http://palosaari.fi/

Re: DVB core enhancements - comments please?

[Mauro Carvalho Chehab]

Em 27-06-2012 21:33, Antti Palosaari escreveu:
> Here is my list of needed DVB core related changes. Feel free to comment - what are not needed or what you would like to see instead. I will try to implement what I can (and what I like most interesting :).
> 
> 
> general validly checking for demodulator callback input values
> --------------------------------------------------
> * currently each driver needs to validate those
> * values are highly hooked up to used television standard
> * we can do almost all validly checking inside core
> * we can also check if call is possible to perform in given condition
> * for example BER is not valid when demod is unlocked
> 
> 
> suspend / resume support
> --------------------------------------------------
> * support is currently quite missing, all what is done is on interface drivers
> * needs power management
> * streaming makes it hard
> * quite a lot work to get it working in case of straming is ongoing
> 
> 
> use Kernel power management instead of own
> --------------------------------------------------
> * there seems to be Kernel services for power-management
> * study if it is wise to use Kernel services instead of own
> * own PM is still working very well, at least I dont know any problems
> 
> 
> SDR - Softaware Defined Radio support DVB API
> --------------------------------------------------
> * http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/44461
> * there is existing devices that are SDR (RTL2832U "rtl-sdr")
> * SDR is quite near what is digital TV streaming
> * study what is needed
> * new delivery system for frontend API called SDR?
> * some core changes needed, like status (is locked etc)
> * how about demuxer?
> * stream conversion, inside Kernel?
> * what are new parameters needed for DVB API?

Let's not mix APIs: the radio control should use the V4L2 API, as this is not
DVB. The V4L2 API has already everything needed for radio. The only missing
part ther is the audio stream. However, there are a few drivers that provide 
audio via the radio device node, using read()/poll() syscalls, like pvrusb. 
On this specific driver, audio comes through a MPEG stream. As SDR provides
audio on a different format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD
to set/retrieve the type of audio stream, for SDR, but maybe it better to just
add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to indicate that
the audio will come though the radio node and if the format is MPEG or SDR.

> 
> 
> DTMB standard support for DVB API
> --------------------------------------------------
> * it is Chinese DTV standard
> * I already ran RFC but have been too busy for implementing it :]
> 
> 
> LNA (low-noise amplifier) support for DVB API
> --------------------------------------------------
> * there is quite a lot of devices having LNA
> * currently not supported => LNA is configured off typically
> 
> 
> offer polling method for statistics
> --------------------------------------------------
> * many static counters could not be read as a "one go"
> * typical cycle is : start measurement => wait => read counters
> * some drivers starts own internal work-queue for polling (complexity)
> * some drivers blocks IOCTL when taking measurement (bad)
> 
> 
> fix frontend properties
> --------------------------------------------------
> * those has been broken since MFE => SFE change
> * currently implemented as a properties per driver
> * need to be properties per delivery system
> * are broken because driver/chip could support multiple DTV standards
> 
> regards
> Antti

Re: DVB core enhancements - comments please?

[Antti Palosaari]

On 06/29/2012 07:32 AM, Mauro Carvalho Chehab wrote:
> Em 27-06-2012 21:33, Antti Palosaari escreveu:
>> SDR - Softaware Defined Radio support DVB API
>> --------------------------------------------------
>> * http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/44461
>> * there is existing devices that are SDR (RTL2832U "rtl-sdr")
>> * SDR is quite near what is digital TV streaming
>> * study what is needed
>> * new delivery system for frontend API called SDR?
>> * some core changes needed, like status (is locked etc)
>> * how about demuxer?
>> * stream conversion, inside Kernel?
>> * what are new parameters needed for DVB API?
>
> Let's not mix APIs: the radio control should use the V4L2 API, as this is not
> DVB. The V4L2 API has already everything needed for radio. The only missing
> part ther is the audio stream. However, there are a few drivers that provide
> audio via the radio device node, using read()/poll() syscalls, like pvrusb.
> On this specific driver, audio comes through a MPEG stream. As SDR provides
> audio on a different format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD
> to set/retrieve the type of audio stream, for SDR, but maybe it better to just
> add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to indicate that
> the audio will come though the radio node and if the format is MPEG or SDR.

SDR is not a radio in mean of V4L2 analog audio radios. SDR can receive 
all kind of signals, analog audio, analog television, digital radio, 
digital television, cellular phones, etc. You can even receive DVB-T, 
but hardware I have is not capable to receive such wide stream.

That chip supports natively DVB-T TS but change be switched to SDR mode. 
Is it even possible to switch from DVB API (DVB-T delivery system) to 
V4L2 API at runtime?


regards
Antti

-- 
http://palosaari.fi/

Re: DVB core enhancements - comments please?

[Patrick Boettcher]

On Friday 29 June 2012 08:03:16 Antti Palosaari wrote:
> On 06/29/2012 07:32 AM, Mauro Carvalho Chehab wrote:
> > Em 27-06-2012 21:33, Antti Palosaari escreveu:
> >> SDR - Softaware Defined Radio support DVB API
> >> --------------------------------------------------
> >> *
> >> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructu
> >> re/44461 * there is existing devices that are SDR (RTL2832U "rtl-sdr")
> >> * SDR is quite near what is digital TV streaming
> >> * study what is needed
> >> * new delivery system for frontend API called SDR?
> >> * some core changes needed, like status (is locked etc)
> >> * how about demuxer?
> >> * stream conversion, inside Kernel?
> >> * what are new parameters needed for DVB API?
> > 
> > Let's not mix APIs: the radio control should use the V4L2 API, as this
> > is not DVB. The V4L2 API has already everything needed for radio. The
> > only missing part ther is the audio stream. However, there are a few
> > drivers that provide audio via the radio device node, using
> > read()/poll() syscalls, like pvrusb. On this specific driver, audio
> > comes through a MPEG stream. As SDR provides audio on a different
> > format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD to
> > set/retrieve the type of audio stream, for SDR, but maybe it better to
> > just add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to
> > indicate that the audio will come though the radio node and if the
> > format is MPEG or SDR.
> SDR is not a radio in mean of V4L2 analog audio radios. SDR can receive
> all kind of signals, analog audio, analog television, digital radio,
> digital television, cellular phones, etc. You can even receive DVB-T,
> but hardware I have is not capable to receive such wide stream.
> 
> That chip supports natively DVB-T TS but change be switched to SDR mode.
> Is it even possible to switch from DVB API (DVB-T delivery system) to
> V4L2 API at runtime?

It could be possible that neither the DVB-API nor the V4L2 API is the right 
user-interface for such devices. The output of such devices is the 
acquisition of raw (digitalized) data of a signal and here signal is meant 
in the sense of anything which can be digitalized (e.g.: sensors, tuners, 
ADCs).

Such device will surely be have a device-specific (user-space?) library to 
do the post/pre-processing before putting this data into a generic format.

That said, IMO, the rtl-sdr driver should sit on the DVB-API. Maybe V4L2 
provides a device-specific control path (to configure the hardware) if not 
somewhere else, or something new needs to be created.

regards,
--
Patrick.

Kernel Labs Inc.
http://www.kernellabs.com/

Re: DVB core enhancements - comments please?

[Antti Palosaari]

On 06/29/2012 02:24 PM, Patrick Boettcher wrote:
> On Friday 29 June 2012 08:03:16 Antti Palosaari wrote:
>> On 06/29/2012 07:32 AM, Mauro Carvalho Chehab wrote:
>>> Em 27-06-2012 21:33, Antti Palosaari escreveu:
>>>> SDR - Softaware Defined Radio support DVB API
>>>> --------------------------------------------------
>>>> *
>>>> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructu
>>>> re/44461 * there is existing devices that are SDR (RTL2832U "rtl-sdr")
>>>> * SDR is quite near what is digital TV streaming
>>>> * study what is needed
>>>> * new delivery system for frontend API called SDR?
>>>> * some core changes needed, like status (is locked etc)
>>>> * how about demuxer?
>>>> * stream conversion, inside Kernel?
>>>> * what are new parameters needed for DVB API?
>>>
>>> Let's not mix APIs: the radio control should use the V4L2 API, as this
>>> is not DVB. The V4L2 API has already everything needed for radio. The
>>> only missing part ther is the audio stream. However, there are a few
>>> drivers that provide audio via the radio device node, using
>>> read()/poll() syscalls, like pvrusb. On this specific driver, audio
>>> comes through a MPEG stream. As SDR provides audio on a different
>>> format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD to
>>> set/retrieve the type of audio stream, for SDR, but maybe it better to
>>> just add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to
>>> indicate that the audio will come though the radio node and if the
>>> format is MPEG or SDR.
>> SDR is not a radio in mean of V4L2 analog audio radios. SDR can receive
>> all kind of signals, analog audio, analog television, digital radio,
>> digital television, cellular phones, etc. You can even receive DVB-T,
>> but hardware I have is not capable to receive such wide stream.
>>
>> That chip supports natively DVB-T TS but change be switched to SDR mode.
>> Is it even possible to switch from DVB API (DVB-T delivery system) to
>> V4L2 API at runtime?
>
> It could be possible that neither the DVB-API nor the V4L2 API is the right
> user-interface for such devices. The output of such devices is the
> acquisition of raw (digitalized) data of a signal and here signal is meant
> in the sense of anything which can be digitalized (e.g.: sensors, tuners,
> ADCs).
>
> Such device will surely be have a device-specific (user-space?) library to
> do the post/pre-processing before putting this data into a generic format.

Generic format for SDR is Complex. I had some plans to do that 
conversion inside Kernel.

> That said, IMO, the rtl-sdr driver should sit on the DVB-API. Maybe V4L2
> provides a device-specific control path (to configure the hardware) if not
> somewhere else, or something new needs to be created.

For me DVB API sounds very easy to implement. At the minimum only new 
delivery system and conversion to Complex. If you skip stream conversion 
and add only new delivery system, it is just single line of code to DVB 
frontend (at the most simplest case).

V4L2 sounds hard for me since I have never done anything with it. But 
surely I can implement it as V4L2 too if it is correct way and there is 
someone who could give some tips how to proceed.

regards
Antti

-- 
http://palosaari.fi/

Re: DVB core enhancements - comments please?

[Patrick Boettcher]

On Friday 29 June 2012 13:24:52 Patrick Boettcher wrote:

> That said, IMO, the rtl-sdr driver should sit on the DVB-API. Maybe V4L2

*argl* I wanted to say, ... should _not_ sit on the DVB-API... 

--
Patrick.

Kernel Labs Inc.
http://www.kernellabs.com/

Re: DVB core enhancements - comments please?

[Mauro Carvalho Chehab]

Em 29-06-2012 08:24, Patrick Boettcher escreveu:
> On Friday 29 June 2012 08:03:16 Antti Palosaari wrote:
>> On 06/29/2012 07:32 AM, Mauro Carvalho Chehab wrote:
>>> Em 27-06-2012 21:33, Antti Palosaari escreveu:
>>>> SDR - Softaware Defined Radio support DVB API
>>>> --------------------------------------------------
>>>> *
>>>> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructu
>>>> re/44461 * there is existing devices that are SDR (RTL2832U "rtl-sdr")
>>>> * SDR is quite near what is digital TV streaming
>>>> * study what is needed
>>>> * new delivery system for frontend API called SDR?
>>>> * some core changes needed, like status (is locked etc)
>>>> * how about demuxer?
>>>> * stream conversion, inside Kernel?
>>>> * what are new parameters needed for DVB API?
>>>
>>> Let's not mix APIs: the radio control should use the V4L2 API, as this
>>> is not DVB. The V4L2 API has already everything needed for radio. The
>>> only missing part ther is the audio stream. However, there are a few
>>> drivers that provide audio via the radio device node, using
>>> read()/poll() syscalls, like pvrusb. On this specific driver, audio
>>> comes through a MPEG stream. As SDR provides audio on a different
>>> format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD to
>>> set/retrieve the type of audio stream, for SDR, but maybe it better to
>>> just add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to
>>> indicate that the audio will come though the radio node and if the
>>> format is MPEG or SDR.
>> SDR is not a radio in mean of V4L2 analog audio radios. SDR can receive
>> all kind of signals, analog audio, analog television, digital radio,
>> digital television, cellular phones, etc. You can even receive DVB-T,
>> but hardware I have is not capable to receive such wide stream.
>>
>> That chip supports natively DVB-T TS but change be switched to SDR mode.
>> Is it even possible to switch from DVB API (DVB-T delivery system) to
>> V4L2 API at runtime?
> 
> It could be possible that neither the DVB-API nor the V4L2 API is the right
> user-interface for such devices. The output of such devices is the
> acquisition of raw (digitalized) data of a signal and here signal is meant
> in the sense of anything which can be digitalized (e.g.: sensors, tuners,
> ADCs).
> 
> Such device will surely be have a device-specific (user-space?) library to
> do the post/pre-processing before putting this data into a generic format.

That's one more reason why using the V4L2 API is better: at the V4L2 API, the
output format is represented by a 32 bits unique code. There are several
standard fourcc codes there, plus several proprietary formats represented.
The decoding between the proprietary formats is done via libv4l. Libv4l
can be used with any pre-compiled userspace application, via LD_PRELOAD,
although almost all V4L2 userspace applications[1] are using the libv4l to decode
data. Adding SDR decoding there should not be hard.

[1] Radio applications don't use it yet, as almost all radio devices output
audio via ALSA API, so some work will be needed there to add SDR radio
support.

>> That said, IMO, the rtl-sdr driver should sit on the DVB-API. Maybe V4L2
>> provides a device-specific control path (to configure the hardware) if not
>> somewhere else, or something new needs to be created.

> *argl* I wanted to say, ... should _not_ sit on the DVB-API...

Agreed. Tuning with the V4L2 API is more direct, as doesn't have any
threads looking for DVB demod status, in order to do frequency zig-zag.

It also have support for hardware frequency scanning, which can be an
interesting feature if supported.

Regards,
Mauro

Re: DVB core enhancements - comments please?

[Antti Palosaari]

On 06/29/2012 05:28 PM, Mauro Carvalho Chehab wrote:
> Em 29-06-2012 08:24, Patrick Boettcher escreveu:
>> On Friday 29 June 2012 08:03:16 Antti Palosaari wrote:
>>> On 06/29/2012 07:32 AM, Mauro Carvalho Chehab wrote:
>>>> Em 27-06-2012 21:33, Antti Palosaari escreveu:
>>>>> SDR - Softaware Defined Radio support DVB API
>>>>> --------------------------------------------------
>>>>> *
>>>>> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructu
>>>>> re/44461 * there is existing devices that are SDR (RTL2832U "rtl-sdr")
>>>>> * SDR is quite near what is digital TV streaming
>>>>> * study what is needed
>>>>> * new delivery system for frontend API called SDR?
>>>>> * some core changes needed, like status (is locked etc)
>>>>> * how about demuxer?
>>>>> * stream conversion, inside Kernel?
>>>>> * what are new parameters needed for DVB API?
>>>>
>>>> Let's not mix APIs: the radio control should use the V4L2 API, as this
>>>> is not DVB. The V4L2 API has already everything needed for radio. The
>>>> only missing part ther is the audio stream. However, there are a few
>>>> drivers that provide audio via the radio device node, using
>>>> read()/poll() syscalls, like pvrusb. On this specific driver, audio
>>>> comes through a MPEG stream. As SDR provides audio on a different
>>>> format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD to
>>>> set/retrieve the type of audio stream, for SDR, but maybe it better to
>>>> just add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to
>>>> indicate that the audio will come though the radio node and if the
>>>> format is MPEG or SDR.
>>> SDR is not a radio in mean of V4L2 analog audio radios. SDR can receive
>>> all kind of signals, analog audio, analog television, digital radio,
>>> digital television, cellular phones, etc. You can even receive DVB-T,
>>> but hardware I have is not capable to receive such wide stream.
>>>
>>> That chip supports natively DVB-T TS but change be switched to SDR mode.
>>> Is it even possible to switch from DVB API (DVB-T delivery system) to
>>> V4L2 API at runtime?
>>
>> It could be possible that neither the DVB-API nor the V4L2 API is the right
>> user-interface for such devices. The output of such devices is the
>> acquisition of raw (digitalized) data of a signal and here signal is meant
>> in the sense of anything which can be digitalized (e.g.: sensors, tuners,
>> ADCs).
>>
>> Such device will surely be have a device-specific (user-space?) library to
>> do the post/pre-processing before putting this data into a generic format.
>
> That's one more reason why using the V4L2 API is better: at the V4L2 API, the
> output format is represented by a 32 bits unique code. There are several
> standard fourcc codes there, plus several proprietary formats represented.
> The decoding between the proprietary formats is done via libv4l. Libv4l
> can be used with any pre-compiled userspace application, via LD_PRELOAD,
> although almost all V4L2 userspace applications[1] are using the libv4l to decode
> data. Adding SDR decoding there should not be hard.
>
> [1] Radio applications don't use it yet, as almost all radio devices output
> audio via ALSA API, so some work will be needed there to add SDR radio
> support.
>
>>> That said, IMO, the rtl-sdr driver should sit on the DVB-API. Maybe V4L2
>>> provides a device-specific control path (to configure the hardware) if not
>>> somewhere else, or something new needs to be created.
>
>> *argl* I wanted to say, ... should _not_ sit on the DVB-API...
>
> Agreed. Tuning with the V4L2 API is more direct, as doesn't have any
> threads looking for DVB demod status, in order to do frequency zig-zag.
>
> It also have support for hardware frequency scanning, which can be an
> interesting feature if supported.

OK, I have now played (too) many hours. Looking existing code and 
testing. But I cannot listen even simple FM-radio station. What are most 
famous / best radio applications ? I tried gnomeradio, gqradio and fmscan...

That is USB radio based si470x chipset.

Jul  3 00:12:18 localhost kernel: [27988.288783] usb 5-2: New USB device 
found, idVendor=10c5, idProduct=819a
Jul  3 00:12:18 localhost kernel: [27988.288787] usb 5-2: New USB device 
strings: Mfr=1, Product=2, SerialNumber=0
Jul  3 00:12:18 localhost kernel: [27988.288789] usb 5-2: Manufacturer: 
www.rding.cn
Jul  3 00:12:18 localhost udevd[409]: specified group 'plugdev' unknown
Jul  3 00:12:18 localhost kernel: [27988.310751] radio-si470x 5-2:1.2: 
DeviceID=0x1242 ChipID=0x060c
Jul  3 00:12:18 localhost kernel: [27988.310754] radio-si470x 5-2:1.2: 
This driver is known to work with firmware version 15,
Jul  3 00:12:18 localhost kernel: [27988.310756] radio-si470x 5-2:1.2: 
but the device has firmware version 12.
Jul  3 00:12:18 localhost kernel: [27988.312750] radio-si470x 5-2:1.2: 
software version 1, hardware version 7
Jul  3 00:12:18 localhost kernel: [27988.312753] radio-si470x 5-2:1.2: 
This driver is known to work with software version 7,
Jul  3 00:12:18 localhost kernel: [27988.312755] radio-si470x 5-2:1.2: 
but the device has software version 1.
Jul  3 00:12:18 localhost kernel: [27988.312756] radio-si470x 5-2:1.2: 
If you have some trouble using this driver,
Jul  3 00:12:18 localhost kernel: [27988.312757] radio-si470x 5-2:1.2: 
please report to V4L ML at linux-media@vger.kernel.org


regards
Antti

-- 
http://palosaari.fi/

Re: DVB core enhancements - comments please?

[Mauro Carvalho Chehab]

Em 02-07-2012 18:27, Antti Palosaari escreveu:
> On 06/29/2012 05:28 PM, Mauro Carvalho Chehab wrote:
>> Em 29-06-2012 08:24, Patrick Boettcher escreveu:
>>> On Friday 29 June 2012 08:03:16 Antti Palosaari wrote:
>>>> On 06/29/2012 07:32 AM, Mauro Carvalho Chehab wrote:
>>>>> Em 27-06-2012 21:33, Antti Palosaari escreveu:
>>>>>> SDR - Softaware Defined Radio support DVB API
>>>>>> --------------------------------------------------
>>>>>> *
>>>>>> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructu
>>>>>> re/44461 * there is existing devices that are SDR (RTL2832U "rtl-sdr")
>>>>>> * SDR is quite near what is digital TV streaming
>>>>>> * study what is needed
>>>>>> * new delivery system for frontend API called SDR?
>>>>>> * some core changes needed, like status (is locked etc)
>>>>>> * how about demuxer?
>>>>>> * stream conversion, inside Kernel?
>>>>>> * what are new parameters needed for DVB API?
>>>>>
>>>>> Let's not mix APIs: the radio control should use the V4L2 API, as this
>>>>> is not DVB. The V4L2 API has already everything needed for radio. The
>>>>> only missing part ther is the audio stream. However, there are a few
>>>>> drivers that provide audio via the radio device node, using
>>>>> read()/poll() syscalls, like pvrusb. On this specific driver, audio
>>>>> comes through a MPEG stream. As SDR provides audio on a different
>>>>> format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD to
>>>>> set/retrieve the type of audio stream, for SDR, but maybe it better to
>>>>> just add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to
>>>>> indicate that the audio will come though the radio node and if the
>>>>> format is MPEG or SDR.
>>>> SDR is not a radio in mean of V4L2 analog audio radios. SDR can receive
>>>> all kind of signals, analog audio, analog television, digital radio,
>>>> digital television, cellular phones, etc. You can even receive DVB-T,
>>>> but hardware I have is not capable to receive such wide stream.
>>>>
>>>> That chip supports natively DVB-T TS but change be switched to SDR mode.
>>>> Is it even possible to switch from DVB API (DVB-T delivery system) to
>>>> V4L2 API at runtime?
>>>
>>> It could be possible that neither the DVB-API nor the V4L2 API is the right
>>> user-interface for such devices. The output of such devices is the
>>> acquisition of raw (digitalized) data of a signal and here signal is meant
>>> in the sense of anything which can be digitalized (e.g.: sensors, tuners,
>>> ADCs).
>>>
>>> Such device will surely be have a device-specific (user-space?) library to
>>> do the post/pre-processing before putting this data into a generic format.
>>
>> That's one more reason why using the V4L2 API is better: at the V4L2 API, the
>> output format is represented by a 32 bits unique code. There are several
>> standard fourcc codes there, plus several proprietary formats represented.
>> The decoding between the proprietary formats is done via libv4l. Libv4l
>> can be used with any pre-compiled userspace application, via LD_PRELOAD,
>> although almost all V4L2 userspace applications[1] are using the libv4l to decode
>> data. Adding SDR decoding there should not be hard.
>>
>> [1] Radio applications don't use it yet, as almost all radio devices output
>> audio via ALSA API, so some work will be needed there to add SDR radio
>> support.
>>
>>>> That said, IMO, the rtl-sdr driver should sit on the DVB-API. Maybe V4L2
>>>> provides a device-specific control path (to configure the hardware) if not
>>>> somewhere else, or something new needs to be created.
>>
>>> *argl* I wanted to say, ... should _not_ sit on the DVB-API...
>>
>> Agreed. Tuning with the V4L2 API is more direct, as doesn't have any
>> threads looking for DVB demod status, in order to do frequency zig-zag.
>>
>> It also have support for hardware frequency scanning, which can be an
>> interesting feature if supported.
> 
> OK, I have now played (too) many hours. Looking existing code and testing. But I cannot listen even simple FM-radio station. What are most famous / best radio applications ? I tried gnomeradio, gqradio and fmscan...
> 
> That is USB radio based si470x chipset.

Well, I don't have any si470x device here.

It should be noticed that radio applications in general don't open the
alsa devices to get audio, as old devices used to have a cable to wire
at the audio adapter.

I bet that this device uses snd-usb-audio module for audio. So, you may
need to use aplayer/arecord in order to listen, with a syntax similar to:

	arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | aplay -

The -r 32000 is for 32 kHz. 


In my case, I prefer to use "radio" aplication that comes with xawtv.
It shouldn't be hard to patch it to also create the audio playback command
there, as the code for that is already there at xawtv3 tree, and it is
used by xawtv.

I'll see if I can write a patch for that today.

> 
> Jul  3 00:12:18 localhost kernel: [27988.288783] usb 5-2: New USB device found, idVendor=10c5, idProduct=819a
> Jul  3 00:12:18 localhost kernel: [27988.288787] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> Jul  3 00:12:18 localhost kernel: [27988.288789] usb 5-2: Manufacturer: www.rding.cn
> Jul  3 00:12:18 localhost udevd[409]: specified group 'plugdev' unknown
> Jul  3 00:12:18 localhost kernel: [27988.310751] radio-si470x 5-2:1.2: DeviceID=0x1242 ChipID=0x060c
> Jul  3 00:12:18 localhost kernel: [27988.310754] radio-si470x 5-2:1.2: This driver is known to work with firmware version 15,
> Jul  3 00:12:18 localhost kernel: [27988.310756] radio-si470x 5-2:1.2: but the device has firmware version 12.
> Jul  3 00:12:18 localhost kernel: [27988.312750] radio-si470x 5-2:1.2: software version 1, hardware version 7
> Jul  3 00:12:18 localhost kernel: [27988.312753] radio-si470x 5-2:1.2: This driver is known to work with software version 7,
> Jul  3 00:12:18 localhost kernel: [27988.312755] radio-si470x 5-2:1.2: but the device has software version 1.
> Jul  3 00:12:18 localhost kernel: [27988.312756] radio-si470x 5-2:1.2: If you have some trouble using this driver,
> Jul  3 00:12:18 localhost kernel: [27988.312757] radio-si470x 5-2:1.2: please report to V4L ML at linux-media@vger.kernel.org
> 
> 
> regards
> Antti
> 

Re: DVB core enhancements - comments please?

[Hin-Tak Leung]

--- On Tue, 3/7/12, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:

<snipped>
> > That is USB radio based si470x chipset.
> 
> Well, I don't have any si470x device here.
> 
> It should be noticed that radio applications in general
> don't open the
> alsa devices to get audio, as old devices used to have a
> cable to wire
> at the audio adapter.
> 
> I bet that this device uses snd-usb-audio module for audio.
> So, you may
> need to use aplayer/arecord in order to listen, with a
> syntax similar to:
> 
>     arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE
> | aplay -
> 
> The -r 32000 is for 32 kHz. 

Quite possibly - shouldn't /proc/bus/usb/devices (or one of the /proc...usb...devices ) gives some clues about what kind of interface/device-class it is? lsusb probably also... 

> > Jul  3 00:12:18 localhost kernel: [27988.288783]
> usb 5-2: New USB device found, idVendor=10c5,
> idProduct=819a
> > Jul  3 00:12:18 localhost kernel: [27988.288787]
> usb 5-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> > Jul  3 00:12:18 localhost kernel: [27988.288789]
> usb 5-2: Manufacturer: www.rding.cn

The vendor's web site has some sort of linux driver for something else. They might be willing to talk.

> > Jul  3 00:12:18 localhost udevd[409]: specified
> group 'plugdev' unknown
> > Jul  3 00:12:18 localhost kernel: [27988.310751]
> radio-si470x 5-2:1.2: DeviceID=0x1242 ChipID=0x060c
> > Jul  3 00:12:18 localhost kernel: [27988.310754]
> radio-si470x 5-2:1.2: This driver is known to work with
> firmware version 15,
> > Jul  3 00:12:18 localhost kernel: [27988.310756]
> radio-si470x 5-2:1.2: but the device has firmware version
> 12.
> > Jul  3 00:12:18 localhost kernel: [27988.312750]
> radio-si470x 5-2:1.2: software version 1, hardware version
> 7
> > Jul  3 00:12:18 localhost kernel: [27988.312753]
> radio-si470x 5-2:1.2: This driver is known to work with
> software version 7,
> > Jul  3 00:12:18 localhost kernel: [27988.312755]
> radio-si470x 5-2:1.2: but the device has software version
> 1.

The two-stage (I assume) firmware message is a bit confusing... can this be improved?

Re: DVB core enhancements - comments please?

[Mauro Carvalho Chehab]

Em 03-07-2012 13:25, Mauro Carvalho Chehab escreveu:
> Em 02-07-2012 18:27, Antti Palosaari escreveu:

>> OK, I have now played (too) many hours. Looking existing code and testing. But I cannot listen even simple FM-radio station. What are most famous / best radio applications ? I tried gnomeradio, gqradio and fmscan...
>>
>> That is USB radio based si470x chipset.
> 
> Well, I don't have any si470x device here.
> 
> It should be noticed that radio applications in general don't open the
> alsa devices to get audio, as old devices used to have a cable to wire
> at the audio adapter.
> 
> I bet that this device uses snd-usb-audio module for audio. So, you may
> need to use aplayer/arecord in order to listen, with a syntax similar to:
> 
> 	arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | aplay -
> 
> The -r 32000 is for 32 kHz.
> 
> 
> In my case, I prefer to use "radio" aplication that comes with xawtv.
> It shouldn't be hard to patch it to also create the audio playback command
> there, as the code for that is already there at xawtv3 tree, and it is
> used by xawtv.
> 
> I'll see if I can write a patch for that today.

Gah, worked on that just to discover that Hans de Goede had added it already...

Anyway, it is good to know that this got already fixed :)

Anyway, "radio" should do the proper alsa loopback handling:

	$ radio
	Using alsa loopback: cap: hw:2,0 (/dev/radio0), out: default

Regards,
Mauro

Re: DVB core enhancements - comments please?

[Mauro Carvalho Chehab]

Em 29-06-2012 02:03, Antti Palosaari escreveu:
> On 06/29/2012 07:32 AM, Mauro Carvalho Chehab wrote:
>> Em 27-06-2012 21:33, Antti Palosaari escreveu:
>>> SDR - Softaware Defined Radio support DVB API
>>> --------------------------------------------------
>>> * http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/44461
>>> * there is existing devices that are SDR (RTL2832U "rtl-sdr")
>>> * SDR is quite near what is digital TV streaming
>>> * study what is needed
>>> * new delivery system for frontend API called SDR?
>>> * some core changes needed, like status (is locked etc)
>>> * how about demuxer?
>>> * stream conversion, inside Kernel?
>>> * what are new parameters needed for DVB API?
>>
>> Let's not mix APIs: the radio control should use the V4L2 API, as this is not
>> DVB. The V4L2 API has already everything needed for radio. The only missing
>> part ther is the audio stream. However, there are a few drivers that provide
>> audio via the radio device node, using read()/poll() syscalls, like pvrusb.
>> On this specific driver, audio comes through a MPEG stream. As SDR provides
>> audio on a different format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD
>> to set/retrieve the type of audio stream, for SDR, but maybe it better to just
>> add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to indicate that
>> the audio will come though the radio node and if the format is MPEG or SDR.
> 
> SDR is not a radio in mean of V4L2 analog audio radios.

Why not? There's nothing at V4L2 API that limits it to analog, otherwise it couldn't
be used by digital cameras.

> SDR can receive all kind of signals, analog audio, analog television, digital radio,
> digital television, cellular phones, etc. You can even receive DVB-T, but hardware I
> have is not capable to receive such wide stream.

The V4L2 API has everything to control receivers. What it doesn't have (and it doesn't make
sense to have, as such thing would just duplicate existing features at DVB API)
are the per delivery-system specific demodulator properties and PID filtering.

> That chip supports natively DVB-T TS but change be switched to SDR mode. Is it even possible
> to switch from DVB API (DVB-T delivery system) to V4L2 API at runtime?

Yes. There are lots of drivers that do that. There are even a few that allow to control the
frontend and demod via DVB API and to receive streams via V4L2 mmap or read API.

Regards,
Mauro

Re: DVB core enhancements - comments please?

[Antti Palosaari]

On 06/29/2012 03:02 PM, Mauro Carvalho Chehab wrote:
> Em 29-06-2012 02:03, Antti Palosaari escreveu:
>> On 06/29/2012 07:32 AM, Mauro Carvalho Chehab wrote:
>>> Em 27-06-2012 21:33, Antti Palosaari escreveu:
>>>> SDR - Softaware Defined Radio support DVB API
>>>> --------------------------------------------------
>>>> * http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/44461
>>>> * there is existing devices that are SDR (RTL2832U "rtl-sdr")
>>>> * SDR is quite near what is digital TV streaming
>>>> * study what is needed
>>>> * new delivery system for frontend API called SDR?
>>>> * some core changes needed, like status (is locked etc)
>>>> * how about demuxer?
>>>> * stream conversion, inside Kernel?
>>>> * what are new parameters needed for DVB API?
>>>
>>> Let's not mix APIs: the radio control should use the V4L2 API, as this is not
>>> DVB. The V4L2 API has already everything needed for radio. The only missing
>>> part ther is the audio stream. However, there are a few drivers that provide
>>> audio via the radio device node, using read()/poll() syscalls, like pvrusb.
>>> On this specific driver, audio comes through a MPEG stream. As SDR provides
>>> audio on a different format, it could make sense to use VIDIOC_S_STD/VIDIOC_G_STD
>>> to set/retrieve the type of audio stream, for SDR, but maybe it better to just
>>> add capabilities flag at VIDIOC_QUERYCTL or VIDIOC_G_TUNER to indicate that
>>> the audio will come though the radio node and if the format is MPEG or SDR.
>>
>> SDR is not a radio in mean of V4L2 analog audio radios.
>
> Why not? There's nothing at V4L2 API that limits it to analog, otherwise it couldn't
> be used by digital cameras.
>
>> SDR can receive all kind of signals, analog audio, analog television, digital radio,
>> digital television, cellular phones, etc. You can even receive DVB-T, but hardware I
>> have is not capable to receive such wide stream.
>
> The V4L2 API has everything to control receivers. What it doesn't have (and it doesn't make
> sense to have, as such thing would just duplicate existing features at DVB API)
> are the per delivery-system specific demodulator properties and PID filtering.
>
>> That chip supports natively DVB-T TS but change be switched to SDR mode. Is it even possible
>> to switch from DVB API (DVB-T delivery system) to V4L2 API at runtime?
>
> Yes. There are lots of drivers that do that. There are even a few that allow to control the
> frontend and demod via DVB API and to receive streams via V4L2 mmap or read API.

Could you give closest example?
In that case I have RTL2832 DVB-T frontend which I want to change SDR 
mode. What are the those existing DVB frontend drivers look example.

regards
Antti


-- 
http://palosaari.fi/

Re: DVB core enhancements - comments please?

[Marko Ristola]

Hi Antti.

My suspend / resume patch implemented "Kaffeine continues viewing channel after resume".
Some of the ideas could be still useful: http://www.spinics.net/lists/linux-dvb/msg19651.html

Rest of this email has a more thorough description.

Regards,
Marko Ristola

On 06/28/2012 03:33 AM, Antti Palosaari wrote:
> Here is my list of needed DVB core related changes. Feel free to comment - what are not needed or what you would like to see instead. I will try to implement what I can (and what I like most interesting :).
>
...
> suspend / resume support
> --------------------------------------------------
> * support is currently quite missing, all what is done is on interface drivers
> * needs power management
> * streaming makes it hard
> * quite a lot work to get it working in case of straming is ongoing


I've implemented Suspend/Resume for Mantis cu1216 in 2007 (PCI DVB-C device):
Kaffeine continued viewing the channel after resume.
When Tuner was idle too long, it was powered off too.

According to Manu Abraham at that time, somewhat smaller patch would have sufficed.
That patch contais nonrelated fixes too, and won't compile now.

Here is the reference (with Manu's answer):
Start of the thread: http://www.spinics.net/lists/linux-dvb/msg19532.html
The patch: http://www.spinics.net/lists/linux-dvb/msg19651.html
Manu's answer: http://www.spinics.net/lists/linux-dvb/msg19668.html

Thoughts about up-to-date implementation
- Bridge (PCI) device must implement suspend/resume callbacks.
- Frontend might need some change (power off / power on callbacks)?
- "save Tuner / DMA transfer state to memory" might be addable to dvb_core.
- Bridge device supporting suspend/resume needs to have a (non-regression)
   fallback for (frontend) devices that don't have a full tested "Kaffeine works"
   suspend/resume implementation yet.
- What changes encrypted channels need?

Marko

Re: DVB core enhancements - comments please?

[Antti Palosaari]

Moikka Marko,

On 06/30/2012 12:44 PM, Marko Ristola wrote:
> My suspend / resume patch implemented "Kaffeine continues viewing
> channel after resume".
> Some of the ideas could be still useful:
> http://www.spinics.net/lists/linux-dvb/msg19651.html
>
> Rest of this email has a more thorough description.
>
> Regards,
> Marko Ristola
>
> On 06/28/2012 03:33 AM, Antti Palosaari wrote:
>> Here is my list of needed DVB core related changes. Feel free to
>> comment - what are not needed or what you would like to see instead. I
>> will try to implement what I can (and what I like most interesting :).
>>
> ...
>> suspend / resume support
>> --------------------------------------------------
>> * support is currently quite missing, all what is done is on interface
>> drivers
>> * needs power management
>> * streaming makes it hard
>> * quite a lot work to get it working in case of straming is ongoing
>
>
> I've implemented Suspend/Resume for Mantis cu1216 in 2007 (PCI DVB-C
> device):
> Kaffeine continued viewing the channel after resume.
> When Tuner was idle too long, it was powered off too.
>
> According to Manu Abraham at that time, somewhat smaller patch would
> have sufficed.
> That patch contais nonrelated fixes too, and won't compile now.
>
> Here is the reference (with Manu's answer):
> Start of the thread: http://www.spinics.net/lists/linux-dvb/msg19532.html
> The patch: http://www.spinics.net/lists/linux-dvb/msg19651.html
> Manu's answer: http://www.spinics.net/lists/linux-dvb/msg19668.html
>
> Thoughts about up-to-date implementation
> - Bridge (PCI) device must implement suspend/resume callbacks.

That is very likely very clear as without those callbacks we cannot so 
anything. It is current situation and it is not working as stream is not 
stopped and driver refuses to unload. What user sees computer never goes 
suspend and freezes.

> - Frontend might need some change (power off / power on callbacks)?

Likely. The initial plan in my mind is to power off frontend in case 
suspend and power on in case of resume. On power off save current 
parameters and on resume re-tune using those old parameters.

> - "save Tuner / DMA transfer state to memory" might be addable to dvb_core.
> - Bridge device supporting suspend/resume needs to have a (non-regression)
>    fallback for (frontend) devices that don't have a full tested
> "Kaffeine works"
>    suspend/resume implementation yet.

Hmm, I did some initial suspend / resume changes for DVB USB when I 
rewrote it recently. On suspend, it just kills all ongoing urbs used for 
streaming. And on resume it resubmit those urbs in order to resume 
streaming. It just works as it doesn't hang computer anymore. What I 
tested applications continued to show same television channels on resume.

The problem for that solution is that it does not have any power 
management as power management is DVB-core responsibility. So it 
continues eating current because chips are not put sleep and due to that 
those DVB-core changes are required.

> - What changes encrypted channels need?

I think none?


regards
Antti

-- 
http://palosaari.fi/

Re: DVB core enhancements - comments please?

[Marko Ristola]

Moikka Antti.


On 07/01/2012 02:11 PM, Antti Palosaari wrote:
> Moikka Marko,
>
-- snip --
>
> Hmm, I did some initial suspend / resume changes for DVB USB when I rewrote it recently. On suspend, it just kills all ongoing urbs used for streaming. And on resume it resubmit those urbs in order to resume streaming. It just works as it doesn't hang computer anymore. What I tested applications continued to show same television channels on resume.
>
> The problem for that solution is that it does not have any power management as power management is DVB-core responsibility. So it continues eating current because chips are not put sleep and due to that those DVB-core changes are required.

I think that runtime (RT) frontend power saving is a different thing.
It isn't necessarily suspend/resume thing.

I implemented runtime Frontend power saving in 2007 on that patch I referenced.
I used dvb-core's existing functionality. Maybe this concept is applicable for you too.

I added into Mantis bridge device initialization following functions:
+                       mantis->fe->ops.tuner_ops.sleep = mantis_dvb_tuner_sleep;
+                       mantis->fe->ops.tuner_ops.init = mantis_dvb_tuner_init;
tuner_ops.{sleep,init} modification had to be the last one.

I maintained in mantis->has_power the frontend's power status.
Maybe I could have read the active status from PCI context too.

The concept was something like:
- dvb-core has responsibility to call tuner_ops.sleep() and tuner_ops.init() when applicable.
- Mantis PCI Bridge driver (or specific USB driver) has responsibility
   to provide sleep and init implementations for the specific device.
- Mantis bridge device will do the whole task of frontend power management, by calling Frontend's
   tear down / initialization functions when necessary.

>
>> - What changes encrypted channels need?
>
> I think none?
>
>
> regards
> Antti
>


Regards,
Marko

Re: DVB core enhancements - comments please?

[Antti Palosaari]

Morjens!

I am now working with that suspend/resume/power-management, as I got LNA 
issues resolved.

On 07/03/2012 08:21 PM, Marko Ristola wrote:
>
> Moikka Antti.
>
>
> On 07/01/2012 02:11 PM, Antti Palosaari wrote:
>> Moikka Marko,
>>
> -- snip --
>>
>> Hmm, I did some initial suspend / resume changes for DVB USB when I
>> rewrote it recently. On suspend, it just kills all ongoing urbs used
>> for streaming. And on resume it resubmit those urbs in order to resume
>> streaming. It just works as it doesn't hang computer anymore. What I
>> tested applications continued to show same television channels on resume.
>>
>> The problem for that solution is that it does not have any power
>> management as power management is DVB-core responsibility. So it
>> continues eating current because chips are not put sleep and due to
>> that those DVB-core changes are required.
>
> I think that runtime (RT) frontend power saving is a different thing.
> It isn't necessarily suspend/resume thing.

Yes it is different thing (DVB-core runtime power-management). But as 
there is currently implemented .init() and .sleep() callbacks both 
frontend and tuner for power management I don't see why not to use those 
for suspend and resume too.

> I implemented runtime Frontend power saving in 2007 on that patch I
> referenced.
> I used dvb-core's existing functionality. Maybe this concept is
> applicable for you too.
>
> I added into Mantis bridge device initialization following functions:
> +                       mantis->fe->ops.tuner_ops.sleep =
> mantis_dvb_tuner_sleep;
> +                       mantis->fe->ops.tuner_ops.init =
> mantis_dvb_tuner_init;
> tuner_ops.{sleep,init} modification had to be the last one.
>
> I maintained in mantis->has_power the frontend's power status.
> Maybe I could have read the active status from PCI context too.
>
> The concept was something like:
> - dvb-core has responsibility to call tuner_ops.sleep() and
> tuner_ops.init() when applicable.
> - Mantis PCI Bridge driver (or specific USB driver) has responsibility
>    to provide sleep and init implementations for the specific device.
> - Mantis bridge device will do the whole task of frontend power
> management, by calling Frontend's
>    tear down / initialization functions when necessary.

I looked it and reads your discussion too. That code seem never ended up 
for Mantis.

But the idea is just basically same: use existing sleep() calls to put 
device sleep on suspend and on resume use init() to wake-up again. You 
stored existing parameters inside driver state and retuned using those 
when set_frontend() get NULL as a parameter. Things has changed a little 
after that and now those parameters are stored already in dvb-frontend 
cache - which means a little less work for driver.

>>> - What changes encrypted channels need?
>>
>> I think none?



So after all, what I think currently, is:
* bridge sets and forwards .suspend() callback to dvb-core
* bridge sets and forwards .resume() callback to dvb-core
* on suspend, dvb-core puts device sleep
* on resume, dvb-core wake-ups device and inits tune (parameters are in 
cache already)

Clearly, put hardware sleep similarly as in case frontend is in sleep, 
but keep userland interface alive (frontend, demux, etc).


There is a quite lot of documentation to learn and overall whole Kernel 
power-managent is very complex. Fortunately driver implementation is 
very simple most cases. Also as changing DVB-core is needed it should be 
extremely care not make any regressions.

regards
Antti

-- 
http://palosaari.fi/

Re: DVB core enhancements - comments please?

[Antti Palosaari]

Marko,

On 07/21/2012 07:36 PM, Antti Palosaari wrote:
> Morjens!
>
> I am now working with that suspend/resume/power-management, as I got LNA
> issues resolved.
>
> On 07/03/2012 08:21 PM, Marko Ristola wrote:
>>
>> Moikka Antti.
>>
>>
>> On 07/01/2012 02:11 PM, Antti Palosaari wrote:
>>> Moikka Marko,
>>>
>> -- snip --
>>>
>>> Hmm, I did some initial suspend / resume changes for DVB USB when I
>>> rewrote it recently. On suspend, it just kills all ongoing urbs used
>>> for streaming. And on resume it resubmit those urbs in order to resume
>>> streaming. It just works as it doesn't hang computer anymore. What I
>>> tested applications continued to show same television channels on
>>> resume.
>>>
>>> The problem for that solution is that it does not have any power
>>> management as power management is DVB-core responsibility. So it
>>> continues eating current because chips are not put sleep and due to
>>> that those DVB-core changes are required.
>>
>> I think that runtime (RT) frontend power saving is a different thing.
>> It isn't necessarily suspend/resume thing.
>
> Yes it is different thing (DVB-core runtime power-management). But as
> there is currently implemented .init() and .sleep() callbacks both
> frontend and tuner for power management I don't see why not to use those
> for suspend and resume too.
>
>> I implemented runtime Frontend power saving in 2007 on that patch I
>> referenced.
>> I used dvb-core's existing functionality. Maybe this concept is
>> applicable for you too.
>>
>> I added into Mantis bridge device initialization following functions:
>> +                       mantis->fe->ops.tuner_ops.sleep =
>> mantis_dvb_tuner_sleep;
>> +                       mantis->fe->ops.tuner_ops.init =
>> mantis_dvb_tuner_init;
>> tuner_ops.{sleep,init} modification had to be the last one.
>>
>> I maintained in mantis->has_power the frontend's power status.
>> Maybe I could have read the active status from PCI context too.
>>
>> The concept was something like:
>> - dvb-core has responsibility to call tuner_ops.sleep() and
>> tuner_ops.init() when applicable.
>> - Mantis PCI Bridge driver (or specific USB driver) has responsibility
>>    to provide sleep and init implementations for the specific device.
>> - Mantis bridge device will do the whole task of frontend power
>> management, by calling Frontend's
>>    tear down / initialization functions when necessary.
>
> I looked it and reads your discussion too. That code seem never ended up
> for Mantis.
>
> But the idea is just basically same: use existing sleep() calls to put
> device sleep on suspend and on resume use init() to wake-up again. You
> stored existing parameters inside driver state and retuned using those
> when set_frontend() get NULL as a parameter. Things has changed a little
> after that and now those parameters are stored already in dvb-frontend
> cache - which means a little less work for driver.
>
>>>> - What changes encrypted channels need?
>>>
>>> I think none?
>
>
>
> So after all, what I think currently, is:
> * bridge sets and forwards .suspend() callback to dvb-core
> * bridge sets and forwards .resume() callback to dvb-core
> * on suspend, dvb-core puts device sleep
> * on resume, dvb-core wake-ups device and inits tune (parameters are in
> cache already)
>
> Clearly, put hardware sleep similarly as in case frontend is in sleep,
> but keep userland interface alive (frontend, demux, etc).

I ended-up still quite much DVB USB driven implementation. DVB-core 
(frontend) is asked only to do retune on resume.

http://git.linuxtv.org/anttip/media_tree.git/commit/4829b70d8acf8c815e783e55e13f57beb3609602
http://git.linuxtv.org/anttip/media_tree.git/commit/ec99a11dc0c92df3c7f2b0b1f02fcddb23636391

It still lacks LNB voltage and tone and LNA handling. But as those are 
quite rare I decided to left those out for now. For LNB there is already 
some logic inside dvb frontend which could be used...

DVB frontend seems to be quite complex currently and due to that I don't 
want to touch it much. There is all kind of quirks including APIv3 / 
APIv5 conversions. I am almost sure half of frontend code could be 
reduced if written from the scratch.

regards
Antti

-- 
http://palosaari.fi/