Re: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
Em 12-05-2011 09:12, HoP escreveu: 2011/5/12 Bjørn Mork bj...@mork.no: Andreas Oberritter o...@linuxtv.org writes: Please try the patches submitted for testing: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html Ah, great! Thanks. Nothing better than a problem already solved. Not solved. Andreas did an attempt to solve it (at least as far as I know patches not get accepted yet), so please report your result of testing. The better is reply to the patches with a Tested-by: This helps me to better handle the patches when analyzing them. PS.: I shouldn't be touching on it until next week, as it is harder for me to work remotely, and I can't test it from here. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
Andreas Oberritter o...@linuxtv.org writes: Please try the patches submitted for testing: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html Ah, great! Thanks. Nothing better than a problem already solved. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
2011/5/12 Bjørn Mork bj...@mork.no: Andreas Oberritter o...@linuxtv.org writes: Please try the patches submitted for testing: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html Ah, great! Thanks. Nothing better than a problem already solved. Not solved. Andreas did an attempt to solve it (at least as far as I know patches not get accepted yet), so please report your result of testing. Honza -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
HoP jpetr...@gmail.com writes: 2011/5/12 Bjørn Mork bj...@mork.no: Andreas Oberritter o...@linuxtv.org writes: Please try the patches submitted for testing: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html Ah, great! Thanks. Nothing better than a problem already solved. Not solved. Andreas did an attempt to solve it (at least as far as I know patches not get accepted yet), so please report your result of testing. Sure. Now, the only machine I've got with DVB cards is running a stock Debian 2.6.32 kernel and I prefer not to mess with that. But I did a quick-n-dirty backport of the API changes to 2.6.32, built a new dvb_core module and loaded that. And the results are good, as expected. All parameters are now in sync. Both these adapters have been tuned by VDR (which uses the new API): bjorn@canardo:/usr/local/src/git/linux-2.6$ /tmp/dvb_fe_test /dev/dvb/adapter0/frontend0 == /dev/dvb/adapter0/frontend0 == name: Philips TDA10023 DVB-C type: FE_QAM == FE_GET_FRONTEND == frequency : 264006739 inversion : off (0) symbol_rate : 690 fec_inner : FEC_NONE (0) modulation: QAM_256 (5) == FE_GET_PROPERTY == [17] DTV_DELIVERY_SYSTEM : SYS_DVBC_ANNEX_AC (1) [03] DTV_FREQUENCY : 264006739 [06] DTV_INVERSION : off (0) [08] DTV_SYMBOL_RATE : 690 [09] DTV_INNER_FEC : FEC_NONE (0) [04] DTV_MODULATION : QAM_256 (5) [35] DTV_API_VERSION : 5.1 [05] DTV_BANDWIDTH_HZ: BANDWIDTH_AUTO (3) bjorn@canardo:/usr/local/src/git/linux-2.6$ /tmp/dvb_fe_test /dev/dvb/adapter1/frontend0 == /dev/dvb/adapter1/frontend0 == name: Philips TDA10023 DVB-C type: FE_QAM == FE_GET_FRONTEND == frequency : 272006739 inversion : off (0) symbol_rate : 690 fec_inner : FEC_NONE (0) modulation: QAM_256 (5) == FE_GET_PROPERTY == [17] DTV_DELIVERY_SYSTEM : SYS_DVBC_ANNEX_AC (1) [03] DTV_FREQUENCY : 272006739 [06] DTV_INVERSION : off (0) [08] DTV_SYMBOL_RATE : 690 [09] DTV_INNER_FEC : FEC_NONE (0) [04] DTV_MODULATION : QAM_256 (5) [35] DTV_API_VERSION : 5.1 [05] DTV_BANDWIDTH_HZ: BANDWIDTH_AUTO (3) I've obviously messed up the API_VERSION, so this is probably more dirty than quick But all the important values, like frequency, inversion and inner_fec, are now in sync. Thanks a lot. Feel free to add Tested-by: Bjørn Mork bj...@mork.no to the whole patch series if that matters to anyone. I'd really like this to go into 2.6.40 if that is possible. It would have been nice to see it in 2.6.32-longerm was well, but I guess that's out of the question since it builds on top of other API changes (DVBT2). Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
I see in drivers/media/dvb/dvb-core/dvb_frontend.c that there is some synchronization between the old and the new API. But it is incomplete: The new FE_GET_PROPERTY will report only cached values, which is whatever the application has written and not the actual tuned values like FE_GET_FRONTEND will. The problem is that FE_GET_PROPERTY only will call fe-ops.get_property even for legacy drivers. It could have fallen back to calling fe-ops.get_frontend followed by a cache synchronization. Is this difference intentional (because it costs too much, doesn't matter, or whatever)? Or should I prepare a patch for dvb_frontend.c? I made a small util comparing the two APIs, basically just doing fd = open(/dev/dvb/adapter0/frontend0, O_RDONLY); ioctl(fd, FE_GET_INFO, fe_info); ioctl(fd, FE_GET_FRONTEND, fe_param); ioctl(fd, FE_GET_PROPERTY, dtv_props); close(fd); and pretty-printing some of the results from the three ioctl()s. It reports typically something like this: bjorn@canardo:~$ /tmp/dvb_fe_test /dev/dvb/adapter1/frontend0 == /dev/dvb/adapter1/frontend0 == name: Philips TDA10023 DVB-C type: FE_QAM == FE_GET_FRONTEND == frequency : 394013477 inversion : off (0) symbol_rate : 690 fec_inner : FEC_NONE (0) modulation: QAM_256 (5) == FE_GET_PROPERTY == [17] DTV_DELIVERY_SYSTEM : SYS_DVBC_ANNEX_AC (1) [03] DTV_FREQUENCY : 39400 [06] DTV_INVERSION : auto (2) [08] DTV_SYMBOL_RATE : 690 [09] DTV_INNER_FEC : FEC_AUTO (9) [04] DTV_MODULATION : QAM_256 (5) [35] DTV_API_VERSION : 5.1 [05] DTV_BANDWIDTH_HZ: BANDWIDTH_AUTO (3) Notice how FE_GET_PROPERTY returns auto settings for inversion and inner_fec, while FE_GET_FRONTEND reports the actual values currently set in the tuner. Also notice how the frequency differs. It's not a big issue I believe, but I do find this a bit confusing as two different apps using different APIs will report different settings. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
On 05/11/2011 08:34 PM, Bjørn Mork wrote: I see in drivers/media/dvb/dvb-core/dvb_frontend.c that there is some synchronization between the old and the new API. But it is incomplete: The new FE_GET_PROPERTY will report only cached values, which is whatever the application has written and not the actual tuned values like FE_GET_FRONTEND will. The problem is that FE_GET_PROPERTY only will call fe-ops.get_property even for legacy drivers. It could have fallen back to calling fe-ops.get_frontend followed by a cache synchronization. Is this difference intentional (because it costs too much, doesn't matter, or whatever)? Or should I prepare a patch for dvb_frontend.c? Please try the patches submitted for testing: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html Regards, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
