DVB power-management on suspend

Back to the power-management again

Last week I finished with DVB power-management, the issue I touched on earlier too when implementing general suspend / resume support for DVB USB. For now I looked how to implement real hardware power saving functionalities when device is suspended. Initial implementation was lacking all the power management, allowing only computer to enter suspend when television was still streaming. All the chips were still left full power state and thus continued draining full current which is simply against Kernel power-management rules.


In order to fix that problem nicely and general level enough I was forced to study issue from multiple perspectives. It is clear that DVB devices are much more complex than usual Kernel drivers. That is coming from the fact there is at least three sub-drivers (USB/PCI-interface, demodulator, RF-tuner) and each of those works quite independent. Fortunately there is existing power-management callbacks (named init and sleep) which are even often implemented. You can consider those equivalent to USB -framework PM callbacks that are named suspend, resume (and reset_resume). Another lucky point here is that DVB-frontend has cache structure, which basically stores all the transmissions parameters used currently. So as we has existing init/sleep callbacks for power-management and all transmission parameters stored, it should be relatively easy to recover device at the state where it was.

• on suspend
• stop remote controller polling (interface driver)
• stop ongoing stream (interface driver)
• sleep demodulator (demodulator driver)
• sleep tuner (RF-tuner driver)
• sleep interface (interface driver)
• return with success to inform Kernel PM device is suspended
• on resume
• wake-up interface (interface driver)
• wake-up tuner (RF-tuner driver)
• wake-up demodulator (demodulator driver)
• acquire DVB-frontend to retune (DVB-core driver)
• resume ongoing stream (interface driver)
• resume remote controller polling (interface driver)
• return with success to inform Kernel PM device is resumed

Simple? Actually it is, due to no need to touch existing demodulator and tuner drivers. And seems to work nicely. What I tested with few USB devices using VLC, all those continued to show same TV-channel just after resumed!

I still have some thoughts to make it more general by moving that functionality partly to the DVB-frontend. Currently process is lead by DVB USB core parts and DVB-frontend is only asked to perform retune. It could be wise to add suspend and resume functions to the DVB-frontend and let the DVB-frontend then call demodulator and tuner driver init & sleep respectively.

sub-driver level power-management issues

During the development I made simple USB power meter in order to see some real life statistics about device current usage. Quick testing with few USB devices reveals we have quite much room for improvements in that area. I will go back to that topic soon when new multimeter I ordered arrives.

device draining around 280mA when in use

learning learning and GPIOs...

Partytime!

I kept extra long weekend holiday, wow! Reason for that was Ilosaarirock festival I attended with friends. Heh, we were there from Friday to Sunday night and back to home late Monday... not surprise I was a little bit tired. There was very good reason to party as my Google Summer of Code project (that Kernel Media project for Linux Foundation) Midterm Evaluations successfully were passed!

GPIOs

GPIO, shorthand for General Purpose Input/Output

implement functionality of LNA API call in real life

I was forced to find out "proper" solution to control LNA (inside Kernel driver) after I added DVB API support for it. Very often those LNAs are controlled by GPIO line or two. Almost every chip has few GPIOs, for DVB -device this means there could be GPIOs on USB/PCI-bridge, demodulator and tuner. LNA commonly is very simple to control, ON or OFF, which means there is no own driver for LNA chip. Controlling this kind of general device specific properties belongs to the bridge driver.

LNA control path

I should write short article about anatomy of DVB-device but as there is no such article yet, lets explains some wiring as background. I used PCTV nanoStick T2 290e during development, but for most others it is just similar. That device LNA is controlled by demodulator GPIO. Here is the control path, from computer to LNA:

PC|bus=USB|chip=bridge|bus=I2C|chip=demodulator|bus=GPIO|chip=LNA

LNA controlling problem

The problem. Bridge wants to set LNA, but LNA is controlled by the demodulator. How to deliver that request to the demodulator driver? Simplest solution is to export function from demodulator driver to perform request. Function like set_lna() or set_gpio() and call that from the bridge driver. Yes, works, used widely, easy to implement, but so home-brew.

Kernel gpiolib framework

After digging Kernel code and documentation I found there is existing GPIO support. I decided to  try that. At the first glance it looked like only for the motherboard GPIO handling and my need is inside device driver. Looking code more I found it was extended to handle GPIO expanders using gpiolib.  This kind of DVB -device could be seen actually as a USB-I2C-GPIO-expander. For the bonus point we get userspace sysfs interface for free! It is very nice to have as it provides easy access for GPIOs during development.

gpiolib sysfs example

For example this is how I can enable (echo 0) and disable (echo 1) LNA in question:
echo 253 > /sys/class/gpio/export
echo 0 > /sys/class/gpio/gpio253/value
echo 1 > /sys/class/gpio/gpio253/value
echo 253 > /sys/class/gpio/unexport

Final notes

I encourage all the other DVB driver developers use same solution for demodulator and tuner GPIOs. It is now learned and found to working at least some level. Implementation seems to be quite simple and interface is standard provided by Kernel gpiolib framework. Look example from the cxd2820r demodulator driver.

[PATCH RFC] add LNA support for DVB API

LNA (Low-noise amplifier)

LNA is small antenna signal amplifier inside DVB device. Usually it is external component located between antenna connector and RF-tuner. There is usually amplifiers between whole signal path but LNAs and those which are inside of device. Normal LNA we have in digital television device is simple on/off. When it is off it bypass signal, causing still some loss, and when it is on it amplifies signal using some static factor. That factor is called gain and unit used usually is Decibel (dB).
There is also LNAs offering more than one gain level. For example external DVB-T/C LNA NXP BGU7033. It does have 3 modes, 10 dB, 5 dB and bypass -2 dB.

LNAs having even more adjustable gain levels are called variable gain amplifier (VGA). Also there is LNAs/VGAs integrated to the RF-tuner... But I am not going to go deeper these two cases as main need for that LNA API addition is simple external LNAs between RF-tuner and antenna connector.


comments for DVB LNA API

[PATCH RFC] add LNA support for DVB API

DTMB support for DVB API

V4L2 SDR API

It has been rather slow progress week. Initially I started studying changes needed to support SDR (Software Defined Radio) via Kernel API. For me it sounds quite easy and logical to extend DVB API for SDR. Just adding new delivery system and implement other relative small changes for DVB-core. After some discussion on Linux-Media mailing list, idea of extending DVB API was refused as V4L2 API is more correct API for that kind of stuff. V4L2 API covers FM-radio, camera, web-camera and analogue television stuff whilst DVB API is used only for digital television. Unfortunately I have quite zero experience from V4L2 devices. After hacking with Silicon Laboratories Si472x based USB FM-radio I decided to leave whole SDR for a while. Have to get more suitable radio for V4L2 learning...

DTMB support for DVB API

After adversity with the SDR I decided to do easier DVB enhancements I planned. DTMB (Digital Terrestrial Multimedia Broadcast) is Chinese digital television standard and there is some existing Linux Kernel drivers for that standard. One of those drivers, HDIC HD29L2, was made by me in last autumn and initial interest is coming from there. Big work for whole DTMB API support was done during last Christmas holiday. I even ran some initial RFCs but never finalized work. Learning many research papers and listing all the used parameters, finding out equivalent ones from the existing API, was quite many working days in that time!


1. [PATCH RFCv3] add DTMB support for DVB API
2. [PATCH RFCv3] add DTMB support for DVB API

PULL-requests for Kernel 3.6

[GIT PULL FOR v3.6] DVB USB v2

I pull requested all the DVB USB changes I did. Quite big patch bomb, 103 change-sets! Those are requested for next possible Kernel 3.6, but it could be delayed to 3.7 if some issues are raised. No comments so far...

[GIT PULL FOR v3.6] DVB USB v2

[GIT PULL FOR v3.6] rtl2832 and misc changes

2nd set I pull requested for the same Kernel was some maintenance stuff, bug fixes and minor enhancements to my existing drivers. I put also a long-awaited RTL2832 DVB-T demodulator driver by Thomas Mair to that set too as I did much work for reviewing it and it does have close relation to my dvb_usb_rtl28xxu driver. Hopefully it gets merged at that time...

[GIT PULL FOR v3.6] rtl2832 and misc changes