Re: em28xx mode switching
On Tue, Oct 13, 2009 at 1:04 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Mon, Oct 12, 2009 at 6:31 PM, Antti Palosaari cr...@iki.fi wrote: I ran this same trap few weeks ago when adding Reddo DVB-C USB Box support to em28xx :) Anyhow, since it is dvb only device I decided to switch from .dvb_gpio to .tuner_gpio to fix the problem. I haven't pull requested it yet. http://linuxtv.org/hg/~anttip/reddo-dvb-c/rev/38f946af568f Antti -- http://palosaari.fi/ You were able to get by with using tuner_gpio instead of dvb_gpio because the Reddo isn't a hybrid device. I'm going to propose removing the calls to em28xx_set_mode() in start_streaming() and stop_streaming(). Given the supported boards that are there, I can regression test: EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850 EM2883_BOARD_HAUPPAUGE_WINTV_HVR_950 EM2880_BOARD_PINNACLE_PCTV_HD_PRO EM2880_BOARD_AMD_ATI_TV_WONDER_HD_600 EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900 EM2880_BOARD_TERRATEC_HYBRID_XS and I cannot regression test: EM2880_BOARD_KWORLD_DVB_310U (I have a strong suspicion this board is currently broken anyway) EM2882_BOARD_TERRATEC_HYBRID_XS (I worked with the authors of this one and can probably get them to test) EM2882_BOARD_EVGA_INDTUBE (I worked with the authors of this one and can probably get them to test) EM2880_BOARD_EMPIRE_DUAL_TV (I worked with the authors of this one and can probably get them to test) EM2881_BOARD_PINNACLE_HYBRID_PRO (this is the board I noticed the problem under) I own a Dazzle Hybrid Stick (2881:eb1a IIRC) which I believe use the same hardware as the Pinnacle Hybrid Pro. I can test it with DVB-T, but only on the weekend (I have only access to DVB-C during the week). EM2883_BOARD_KWORLD_HYBRID_330U EM2870_BOARD_REDDO_DVB_C_USB_BOX Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- Alain Perrot -- 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: em28xx mode switching
On Tue, Oct 13, 2009 at 2:27 PM, xwang1...@email.it wrote: Hi Devin, let me know if you need a tester for the EMPIRE_DUAL_TV. In case I will install the latest v4l driver on my old notebook which has a clean kubuntu 9.04 distro. On the newer notebook I'm using my new Dikom DK-300 device which does not work with the latest v4l drivers and which I can use using a patched version of the main v4l driver (thanks to Dainius Ridzevicius). If you have some spare time for this device too... Xwang Hi xwang, Well, I'm hoping to setup a tree sometime this week (and test it with my devices). Assuming it works, I will put out a call for testers such as yourself. Regarding your DK-300, if you send the diff between the main v4l driver and the patched version, we can take a look at what would be required to merge it upstream. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: em28xx mode switching
Hi Devin, let me know if you need a tester for the EMPIRE_DUAL_TV. In case I will install the latest v4l driver on my old notebook which has a clean kubuntu 9.04 distro. On the newer notebook I'm using my new Dikom DK-300 device which does not work with the latest v4l drivers and which I can use using a patched version of the main v4l driver (thanks to Dainius Ridzevicius). If you have some spare time for this device too... Xwang Devin Heitmueller ha scritto: On Mon, Oct 12, 2009 at 6:31 PM, Antti Palosaari cr...@iki.fi wrote: I ran this same trap few weeks ago when adding Reddo DVB-C USB Box support to em28xx :) Anyhow, since it is dvb only device I decided to switch from .dvb_gpio to .tuner_gpio to fix the problem. I haven't pull requested it yet. http://linuxtv.org/hg/~anttip/reddo-dvb-c/rev/38f946af568f Antti -- http://palosaari.fi/ You were able to get by with using tuner_gpio instead of dvb_gpio because the Reddo isn't a hybrid device. I'm going to propose removing the calls to em28xx_set_mode() in start_streaming() and stop_streaming(). Given the supported boards that are there, I can regression test: EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850 EM2883_BOARD_HAUPPAUGE_WINTV_HVR_950 EM2880_BOARD_PINNACLE_PCTV_HD_PRO EM2880_BOARD_AMD_ATI_TV_WONDER_HD_600 EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900 EM2880_BOARD_TERRATEC_HYBRID_XS and I cannot regression test: EM2880_BOARD_KWORLD_DVB_310U (I have a strong suspicion this board is currently broken anyway) EM2882_BOARD_TERRATEC_HYBRID_XS (I worked with the authors of this one and can probably get them to test) EM2882_BOARD_EVGA_INDTUBE (I worked with the authors of this one and can probably get them to test) EM2880_BOARD_EMPIRE_DUAL_TV (I worked with the authors of this one and can probably get them to test) EM2881_BOARD_PINNACLE_HYBRID_PRO (this is the board I noticed the problem under) EM2883_BOARD_KWORLD_HYBRID_330U EM2870_BOARD_REDDO_DVB_C_USB_BOX Devin -- 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
em28xx mode switching
I was debugging an issue on a user's hybrid board, when I realized that we are switching the em28xx mode whenever we start and stop dvb streaming. We already have the ts_bus_ctrl callback implemented which puts the device into digital mode and puts it back into suspend whenever the frontend is opened/closed. This call seems redundant, and in fact can cause problems if the dvb_gpio definition strobes the reset pin, as it can put the driver out of sync with the demodulator's state (in fact this is what I ran into with the zl10353 - the reset pin got strobed when the streaming was started but the demod driver's init() routine was not being run because it already ran when the frontend was originally opened). The only case I can think of where toggling the device mode when starting/stopping dvb streaming might be useful is if we wanted to support being able to do an analog tune while the dvb frontend was still open but not streaming. However, this seems like this could expose all sorts of bugs, and I think the locking would have to be significantly reworked if this were a design goal. Thoughts anybody? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: em28xx mode switching
On 10/13/2009 01:12 AM, Devin Heitmueller wrote: I was debugging an issue on a user's hybrid board, when I realized that we are switching the em28xx mode whenever we start and stop dvb streaming. We already have the ts_bus_ctrl callback implemented which puts the device into digital mode and puts it back into suspend whenever the frontend is opened/closed. This call seems redundant, and in fact can cause problems if the dvb_gpio definition strobes the reset pin, as it can put the driver out of sync with the demodulator's state (in fact this is what I ran into with the zl10353 - the reset pin got strobed when the streaming was started but the demod driver's init() routine was not being run because it already ran when the frontend was originally opened). The only case I can think of where toggling the device mode when starting/stopping dvb streaming might be useful is if we wanted to support being able to do an analog tune while the dvb frontend was still open but not streaming. However, this seems like this could expose all sorts of bugs, and I think the locking would have to be significantly reworked if this were a design goal. Thoughts anybody? Devin I ran this same trap few weeks ago when adding Reddo DVB-C USB Box support to em28xx :) Anyhow, since it is dvb only device I decided to switch from .dvb_gpio to .tuner_gpio to fix the problem. I haven't pull requested it yet. http://linuxtv.org/hg/~anttip/reddo-dvb-c/rev/38f946af568f Antti -- http://palosaari.fi/ -- 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: em28xx mode switching
Am Montag, den 12.10.2009, 18:12 -0400 schrieb Devin Heitmueller: I was debugging an issue on a user's hybrid board, when I realized that we are switching the em28xx mode whenever we start and stop dvb streaming. We already have the ts_bus_ctrl callback implemented which puts the device into digital mode and puts it back into suspend whenever the frontend is opened/closed. This call seems redundant, and in fact can cause problems if the dvb_gpio definition strobes the reset pin, as it can put the driver out of sync with the demodulator's state (in fact this is what I ran into with the zl10353 - the reset pin got strobed when the streaming was started but the demod driver's init() routine was not being run because it already ran when the frontend was originally opened). The only case I can think of where toggling the device mode when starting/stopping dvb streaming might be useful is if we wanted to support being able to do an analog tune while the dvb frontend was still open but not streaming. However, this seems like this could expose all sorts of bugs, and I think the locking would have to be significantly reworked if this were a design goal. Thoughts anybody? Devin Hi, on dvb were some telling us previously, by far not all, but the loudest, all the hybrid stuff will soon vanish and it is not even worth to look closer into it. This is years back, and the problem is still there. But, these days you can discuss it more relaxed and despite of all, we have lots of improvements now. See Mike's latest compromising about who has the gpio pins. Even only thinking about such in public was a crime previously ... (and heavily punished ;) Cheers, Hermann -- 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
