DVB-frontend statistic IOCTLsAs I mentioned earlier there is some IOCTLs to request signal statistic from the device. Namely those IOCTLs are:
- read status flags (am I correctly tuned to channel)
- read bit error rate
- read signal strength
- read signal / noise ratio (signal quality)
- read broken packets (errors seen in picture)
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-managementThat 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_resumeThere was also one USB device specific issue which seems to be now resolved. USB driver model offers 3 callbacks for suspend / resume.
Common DTV standard parameter validationThere 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
- 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...
This comment has been removed by a blog administrator.ReplyDelete