GSoC is over soon

DVB-frontend statistic IOCTLs

As I mentioned earlier there is some IOCTLs to request signal statistic from the device. Namely those IOCTLs are:

• FE_READ_STATUS
• read status flags (am I correctly tuned to channel)
• FE_READ_BER
• read  bit error rate
• FE_READ_SIGNAL_STRENGTH
• read signal strength
• FE_READ_SNR
• read signal / noise ratio (signal quality)
• FE_READ_UNCORRECTED_BLOCKS
•  read broken packets (errors seen in picture)

All of those are valid on certain conditions but not always. For example FE_READ_UNCORRECTED_BLOCKS is valid only when demodulator is locked to television channel and picture is streaming. When device is sleeping it cannot perform any of those and garbage was returned or in worst case even I/O error is raised as chip is unable to communicate.

My plan was first to add some logic to allow IOCTLs according to demodulator status flags (same as FE_READ_STATUS). After some study I found it is quite impossible as current drivers does not report all flags correctly - many times it is just all or nothing. No lock at all or all flags which means demodulator is fully locked and streaming. Due to that I ended up slightly simpler solution, just allow those IOCTLs when frontend is running (not sleeping).

All of those mentioned IOCTLs are optional. Average hardware could report quite likely almost 100% all of those but not always. On the other hand driver writers are lazy or they don't have all the needed information which leads to situation IOCTLs are not implemented. When IOCTL is not implemented error status ENOTTY should be reported. I changed error code to meet that  practice too.

DVB-frontend suspend / resume / power-management

That was maybe third time I am back with suspend / resume / power-management issues during that summer. Earlier I implemented it highly as a part of DVB-USB -framework (that I rewrote largely earlier this summer). Anyhow, logically some suspend / resume functionality belongs more for common DVB-frontend part than routines which are only for DVB-USB devices. So I split relevant parts from the DVB-USB and moved those to the DVB-frontend that all DVB device drivers could take advantage.

These are new routines offered by DVB-frontend / DVB-core:
int dvb_frontend_suspend(struct dvb_frontend *fe)
int dvb_frontend_resume(struct dvb_frontend *fe)

DVB-USB reset_resume

There was also one USB device specific issue which seems to be now resolved. USB driver model offers 3 callbacks for suspend / resume.

• suspend
• resume
• reset_resume

The extra and problematic one is reset_resume. It is quite similar than normal resume but for some reason (like BIOS implementation / bug) USB has reset during suspend/resume. Fortunately my motherboard has extra USB3.0 controller which did reset_resume whilst the USB2.0 controllers integrated to south-bridge did normal resume. Because of that I was able to test both cases and find out proper implementation.

Common DTV standard parameter validation

There is quite many possible parameters which could be programmed to frontend in order to tune to television channel. Parameters are defined in different standards. All values are not valid for every standard and also different partly parameters are used. I have seen it quite hard to validate parameters and allowed combinations inside device driver. That makes me wonder if some common routines per standard are useful...
After all I added few routines for most common standards, which I was familiar. Those are DVB-T, DVB-T2, DVB-C (Annex A) and DTMB. I didn't added more as it was very time consuming to find out needed information from many specifications. For example DVB-C, there was at least three different papers to look:

• EN 300 429
• European Telecommunications Standards Institute
• main specification
• ITU-T J.83
• The International Telecommunication Union
• some additions (Annex A/B/C)
• NorDig Unified Test specification
• NorDig
• real life requirements for digital televisions
• for example frequency limits

Working with that task I take note that these are not listed properly even Kernel documentation. Kernel documentation is place where application developers will likely try to find out possible parameters at the very first. There is clear need to document these correctly...