Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
What happens if you revert this back to the code from my original patch, and include your changes listed below? IE: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); 1) Do you still lock no signal lock issues. MythTV says 'no lock' (though I don't know if such a message is reliable) 2) Do you see normal video as you'd typically expect? Nope, just a black screen. Did not test it with TVheadend. However, in MythTV (0.27.4) the line si2168_set_ts_mode(fe, 0); makes it work. Thanks for helping! :) You're welcome. Thx. I'll spin up a couple of other si2168 boards I have and look at their status, pre-post patch. -- Steven Toth - 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Op 22-07-15 om 14:55 schreef Steven Toth: On Wed, Jul 22, 2015 at 3:15 AM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, I'm happy to inform you that all failures have vanished. Thanks. Summarizing: I compiled 4.2-RC3 with your patch and with /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 0); What happens if you revert this back to the code from my original patch, and include your changes listed below? IE: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); 1) Do you still lock no signal lock issues. MythTV says 'no lock' (though I don't know if such a message is reliable) 2) Do you see normal video as you'd typically expect? Nope, just a black screen. Did not test it with TVheadend. However, in MythTV (0.27.4) the line si2168_set_ts_mode(fe, 0); makes it work. Thanks for helping! :) You're welcome. -- 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Hi Steven,
I'm happy to inform you that all failures have vanished.
Summarizing:
I compiled 4.2-RC3 with your patch and with
/* Tri-state the TS bus */
si2168_set_ts_mode(fe, 0);
changed the .delsys line in si2168.c to satisfy MythTV from
.delsys = {SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A},
to
.delsys = {SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2},
added the dvbloopback module (for descrambling with MythTV) and saa716x
bridge driver (to support my TBS 6285 cards)
Result: lock and tune is just fine in both TVheadend and MythTV with TBS
6285 as well as DVBSky T982 cards.
TBS 6285: saa716x+si2168+si2157
DVBSky T982: cx23885+si2168+si2157
Regards,
Tycho.
Op 21-07-15 om 21:00 schreef Steven Toth:
On Tue, Jul 21, 2015 at 2:07 PM, Tycho Lürsen tycholur...@gmail.com wrote:
Op 21-07-15 om 18:19 schreef Steven Toth:
On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen tycholur...@gmail.com
wrote:
Hi Steven,
I was too curious to wait for you and Antti to settle your differences,
so I
tested again against a 4.2-RC2
I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees
the first system in the .delsys line in si2168.c,
so when it looks like this:
SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2
I'm good.
We have no differences, its Antti's si2168 driver. If Antti doesn't
like the approach for tri-stating, he's free to suggest and
alternative. I suggested two alternatives yesterday.
Result:
With your patch both MythTV and Tvheadend still can't tune. Without it,
everything is ok.
I'm not very interested in czap results, only in real use cases. For me
that's MythTV, but just to be sure I also tested with TVheadend.
That's pretty bizarre results, although thank you for testing. :)
When you say it can't tune, do you mean the signal does not lock, or
that no video appears?
No lock, or partial lock.
Thanks.
That's even worse than expected, given that the patch adjusts the TS
interface, and has nothing to do with tuning, lock, rf or signal
status. It still feels like something else is going on, some other
unexpected race for example.
I can't reproduce that behavior, but given that you can Can you
please try this? in si2168.c, change:
/* Tri-state the TS bus */
si2168_set_ts_mode(fe, 1);
to
/* Tri-state the TS bus */
si2168_set_ts_mode(fe, 0);
... recompile and retest?
Thx.
--
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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Wed, Jul 22, 2015 at 3:15 AM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, I'm happy to inform you that all failures have vanished. Thanks. Summarizing: I compiled 4.2-RC3 with your patch and with /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 0); What happens if you revert this back to the code from my original patch, and include your changes listed below? IE: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); 1) Do you still lock no signal lock issues. 2) Do you see normal video as you'd typically expect? Thanks for helping! :) -- Steven Toth - 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. Regards, Tycho. Op 20-07-15 om 18:32 schreef Steven Toth: On Mon, Jul 20, 2015 at 12:06 PM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, I was not aware of the fact that your patch depends on dvb-core as in 4.2-RC2 (and up, I guess) I tested against 3.18.18 and 4.1.2. That might explain the failures. Anyhow, as soon as Antti and you are on the same page regarding this patch, I'll test again against a 4.2-RC1 Regards, Tycho. Thank you Tycho. I specifically only tested on 4.2, with the entire tree. No attempt was made to backport or otherwise test in environments outside on prior kernels. - Steve -- 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? -- Steven Toth - 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Op 21-07-15 om 18:19 schreef Steven Toth: On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? No lock, or partial lock. -- 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Op 21-07-15 om 21:02 schreef Steven Toth: On Tue, Jul 21, 2015 at 2:59 PM, Tycho Lürsen tycholur...@gmail.com wrote: Op 21-07-15 om 20:07 schreef Tycho Lürsen: Op 21-07-15 om 18:19 schreef Steven Toth: On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? No lock, or partial lock. I've compiled a 4.2-RC3, this time without support for my TBS 6285 cards (so no saa716x) and without dvbloopback kernel module (so no MythTV) Result with your patch and only DVBSky T982 cards: TVheadend is fine with it. Lock and tune are OK. Going to test some more scenario's, I'll keep you informed. Regards, Tycho Thank you sir. In which case, please disregard my last email relating to changing: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); - Steve I've screwed up, last test was without your patch, sorry. I'll recompile with your suggested change. -- 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Tue, Jul 21, 2015 at 2:07 PM, Tycho Lürsen tycholur...@gmail.com wrote: Op 21-07-15 om 18:19 schreef Steven Toth: On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? No lock, or partial lock. Thanks. That's even worse than expected, given that the patch adjusts the TS interface, and has nothing to do with tuning, lock, rf or signal status. It still feels like something else is going on, some other unexpected race for example. I can't reproduce that behavior, but given that you can Can you please try this? in si2168.c, change: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); to /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 0); ... recompile and retest? Thx. -- Steven Toth - 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Tue, Jul 21, 2015 at 2:59 PM, Tycho Lürsen tycholur...@gmail.com wrote: Op 21-07-15 om 20:07 schreef Tycho Lürsen: Op 21-07-15 om 18:19 schreef Steven Toth: On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? No lock, or partial lock. I've compiled a 4.2-RC3, this time without support for my TBS 6285 cards (so no saa716x) and without dvbloopback kernel module (so no MythTV) Result with your patch and only DVBSky T982 cards: TVheadend is fine with it. Lock and tune are OK. Going to test some more scenario's, I'll keep you informed. Regards, Tycho Thank you sir. In which case, please disregard my last email relating to changing: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); - Steve -- Steven Toth - 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Op 21-07-15 om 20:07 schreef Tycho Lürsen: Op 21-07-15 om 18:19 schreef Steven Toth: On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? No lock, or partial lock. I've compiled a 4.2-RC3, this time without support for my TBS 6285 cards (so no saa716x) and without dvbloopback kernel module (so no MythTV) Result with your patch and only DVBSky T982 cards: TVheadend is fine with it. Lock and tune are OK. Going to test some more scenario's, I'll keep you informed. Regards, Tycho -- 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Op 21-07-15 om 21:00 schreef Steven Toth: On Tue, Jul 21, 2015 at 2:07 PM, Tycho Lürsen tycholur...@gmail.com wrote: Op 21-07-15 om 18:19 schreef Steven Toth: On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, I was too curious to wait for you and Antti to settle your differences, so I tested again against a 4.2-RC2 I did not disable DVB-T/T2, instead I reordered the lot. MythTV just sees the first system in the .delsys line in si2168.c, so when it looks like this: SYS_DVBC_ANNEX_A, SYS_DVBT, SYS_DVBT2 I'm good. We have no differences, its Antti's si2168 driver. If Antti doesn't like the approach for tri-stating, he's free to suggest and alternative. I suggested two alternatives yesterday. Result: With your patch both MythTV and Tvheadend still can't tune. Without it, everything is ok. I'm not very interested in czap results, only in real use cases. For me that's MythTV, but just to be sure I also tested with TVheadend. That's pretty bizarre results, although thank you for testing. :) When you say it can't tune, do you mean the signal does not lock, or that no video appears? No lock, or partial lock. Thanks. That's even worse than expected, given that the patch adjusts the TS interface, and has nothing to do with tuning, lock, rf or signal status. It still feels like something else is going on, some other unexpected race for example. I can't reproduce that behavior, but given that you can Can you please try this? in si2168.c, change: /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 1); to /* Tri-state the TS bus */ si2168_set_ts_mode(fe, 0); ... recompile and retest? Thx. I recompiled and tested with this change (still without saa716x or dvbloopback) with TVheadend and all is well. Going to test this with dvbloopback, and if all goes well with saa716x too. But not today. Regards, Tycho. -- 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Mon, Jul 20, 2015 at 2:00 AM, Tony Chang(Wincomm) to...@wincomm.com.tw wrote: Dear : Steven Sorry for my poor english !! I don’t know how to install it According your feedback.. diff --git a/drivers/media/pci/cx23885/Kconfig b/drivers/media/pci/cx23885/Kconfigindex 2e1b88c..3e6398f 100644 I don't how to use diff -- because can't see any drivers/media/ Please reference attached picture Is kernel not support ? Best Regards Tony / Jerry, You need to download the entire tree, based on branch hvr-1275, commit #91bd0a5bbbc3759bb3fd6516d8c322b030620b46, compile and install the entire kernel (which is a 4.2 rc). Its available for download from here: http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275 After that it should be fine. The pictures you have show we're using the same hardware, but you're not running the newer kernel (including the new patches). - Steve -- Steven Toth - 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Sun, Jul 19, 2015 at 3:34 AM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, Tested your si2186 patch with my DVBSky T982 and TBS 6285 cards using European DVB-C Since MythTV can't handle multistandard frontends (yet), I've disabled DVB-T/T2 like this (I always do that): sed -i 's/SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A/SYS_DVBC_ANNEX_A/' drivers/media/dvb-frontends/si2168.c Result: both DVBSky T982 and TBS 6285 drivers are broken, meaning no lock, no tune. Regards, Tycho. Op 19-07-15 om 00:21 schreef Steven Toth: http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275 Patches above are available for test. Antti, note the change to SI2168 to add support for enabling and disabling the SI2168 transport bus dynamically. I've tested with a combo card, switching back and forward between QAM and DVB-T, this works fine, just remember to select a different frontend as we have two frontends on the same adapter, adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2. If any testers have the ATSC or DVB-T, I'd expect these to work equally well, replease report feedback here. Thanks, - Steve Interesting, although I'm slightly confused. My patch mere added the ability for dvb-core to tri-state the tsport out bus, similar to other digital demodulator drivers in the tree and testing with both azap and tzap (and dvbtraffic) showed no tuning, lock or other issues. What happens if you tzap/czap a known good frequency, before and after my patch, without your sed replacement, leaving T/T2 and A fully enabled? - Steve -- Steven Toth - 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On 07/19/2015 01:21 AM, Steven Toth wrote: http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275 Patches above are available for test. Antti, note the change to SI2168 to add support for enabling and disabling the SI2168 transport bus dynamically. I've tested with a combo card, switching back and forward between QAM and DVB-T, this works fine, just remember to select a different frontend as we have two frontends on the same adapter, adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2. If any testers have the ATSC or DVB-T, I'd expect these to work equally well, replease report feedback here. That does not work. I added debug to see what it does and result is that whole si2168_set_ts_mode() function is called only once - when frontend is opened first time. I used dvbv5-scan. I am not sure why you even want to that. Is it because of 2 demods are connected to same TS bus? So you want disable always another? Or is is just power-management, as leaving TS active leaks potentially some current. Anyway, if you want control TS as runtime why you just don't add TS disable to si2168_sleep()? If you enable TS on si2168_init() then correct place to disable it is si2168_sleep(). regards 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Mon, Jul 20, 2015 at 10:30 AM, Antti Palosaari cr...@iki.fi wrote:
On 07/19/2015 01:21 AM, Steven Toth wrote:
http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275
Patches above are available for test.
Antti, note the change to SI2168 to add support for enabling and
disabling the SI2168 transport bus dynamically.
I've tested with a combo card, switching back and forward between QAM
and DVB-T, this works fine, just remember to select a different
frontend as we have two frontends on the same adapter,
adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2.
If any testers have the ATSC or DVB-T, I'd expect these to work
equally well, replease report feedback here.
That does not work. I added debug to see what it does and result is that
whole si2168_set_ts_mode() function is called only once - when frontend is
opened first time. I used dvbv5-scan.
That works very reliably for me, in the 4.2 rc kernel, when using
azap, tzap and dvbtraffic. They're v3 api's of course, but dvb-core
should take care of the differences. Specifically, dvb_frontend.c
dvb_frontend_open() and dvb_frontend_release().
With additional debug added, I clearly saw the syncronization and
acquiring and releasing (via ts_bus_control) of the bus, with each
demodulator.
I am not sure why you even want to that. Is it because of 2 demods are
connected to same TS bus? So you want disable always another? Or is is just
power-management, as leaving TS active leaks potentially some current.
Two demods are on the same bus, so we need to disable the non-active
demod, to ensure the active demodulator can correctly drive the
transport interface.
Anyway, if you want control TS as runtime why you just don't add TS disable
to si2168_sleep()? If you enable TS on si2168_init() then correct place to
disable it is si2168_sleep().
That's what dvb-core does, today in:
dvb_frontend_open()
if (dvbdev-users == -1 fe-ops.ts_bus_ctrl) {
if ((ret = fe-ops.ts_bus_ctrl(fe, 1)) 0)
goto err0;
and in dvb_frontend_release()...
if (fe-ops.ts_bus_ctrl)
fe-ops.ts_bus_ctrl(fe, 0);
The first user of the device ensures ts_bus_control is called when its
enabled, bring the demodulator on to the bus.
The last user of the device ensures ts_bus_control is called when the
device is no longer required.
Why build tristating mode control into the demod specific driver when
its been supported in the core for a long time?
It won't prevent multiple callers from opening two different frontends
(0/1) at the same time, but lack of shared resource management has
been the case on dvb-core (and v4l2) for quite a while.
If you have use case that isn't working, I'm happy to discuss.
--
Steven Toth - 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
We can agree or disagree about whether a part should be tri-stated in init/sleep() and under what circumstances, but why bother when someone has gone to the trouble of declaring a perfectly good tr-state interface in dvb-core, taht automatically asserts and de-asserts any dvb_frontend device from the bus, optionally. Because I simply don't want to any new demod users for that callback unless needed for some strange reason. I see, I understand your concern, perhaps you should have raised this in your first response. Are you the maintainer for dvb-core now? So two options come to mind: 1. The si2168_init() brings the part onto the bus, and _sleep() takes the device off the bus, regardless? Any by default, the device is not on the bus after attach takes place. 2. The bridge specifically calls ts_bus_control() on the si2168 fe ops, as and when the bridge requires it? This feels like a reasonable middle-ground approach. Your thoughts? -- Steven Toth - 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Hi Steven, I was not aware of the fact that your patch depends on dvb-core as in 4.2-RC2 (and up, I guess) I tested against 3.18.18 and 4.1.2. That might explain the failures. Anyhow, as soon as Antti and you are on the same page regarding this patch, I'll test again against a 4.2-RC1 Regards, Tycho. Op 20-07-15 om 15:13 schreef Steven Toth: On Sun, Jul 19, 2015 at 3:34 AM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, Tested your si2186 patch with my DVBSky T982 and TBS 6285 cards using European DVB-C Since MythTV can't handle multistandard frontends (yet), I've disabled DVB-T/T2 like this (I always do that): sed -i 's/SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A/SYS_DVBC_ANNEX_A/' drivers/media/dvb-frontends/si2168.c Result: both DVBSky T982 and TBS 6285 drivers are broken, meaning no lock, no tune. Regards, Tycho. Op 19-07-15 om 00:21 schreef Steven Toth: http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275 Patches above are available for test. Antti, note the change to SI2168 to add support for enabling and disabling the SI2168 transport bus dynamically. I've tested with a combo card, switching back and forward between QAM and DVB-T, this works fine, just remember to select a different frontend as we have two frontends on the same adapter, adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2. If any testers have the ATSC or DVB-T, I'd expect these to work equally well, replease report feedback here. Thanks, - Steve Interesting, although I'm slightly confused. My patch mere added the ability for dvb-core to tri-state the tsport out bus, similar to other digital demodulator drivers in the tree and testing with both azap and tzap (and dvbtraffic) showed no tuning, lock or other issues. What happens if you tzap/czap a known good frequency, before and after my patch, without your sed replacement, leaving T/T2 and A fully enabled? - Steve -- 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On 07/20/2015 08:14 PM, Steven Toth wrote: On Mon, Jul 20, 2015 at 12:54 PM, Antti Palosaari cr...@iki.fi wrote: On 07/20/2015 07:45 PM, Devin Heitmueller wrote: Look at the em28xx driver and you will probably see why it does not work as expected. For my eyes, according to em28xx driver, it looks like that bus control is aimed for bridge driver. You or em28xx is wrong. Neither are wrong. In some cases the call needs to be intercepted by the frontend in order to disable its TS output. In other cases it needs to be intercepted by the bridge to control a MUX chip which dictates which demodulator's TS output to route from (typically by toggling a GPIO). Quickly looking the existing use cases and I found only lgdt3306a demod which uses that callback to control its TS interface. All the rest seems to be somehow more related to bridge driver, mostly changing bridge TS IF or leds etc. The API is flexible enough to be used by either the bridge intercepting the dvb_frontent_open operation, or by allowing the demodulator itself to act upon it. The API itself specifically describes the TS BUS CONTROL access, and whether something upstream of the demodulator wants a downstream device attached, or detached from the transport electrical interface. I see little point adding more bridge glue to route each dvb frontend into the cx23885-bridge and making a judgement based on the board type, when dvb-core is already effectively doing this, and has been for sometime. The caveat to this, is if you find a use-case that breaks the current driver in the current tip kernel. I currently do not see that. I don't simply see that correct solution for disabling demod TS IF - there is sleep() for this kind of things - and as I pointed out it does not even work for me em28xx based device because em28xx uses that routine to switch own TS mode. Asking a demodulator to sleep/wake is absolutely not the same thing as asking it to stop/start driving electrical signals on a bus. We can agree or disagree about whether a part should be tri-stated in init/sleep() and under what circumstances, but why bother when someone has gone to the trouble of declaring a perfectly good tr-state interface in dvb-core, taht automatically asserts and de-asserts any dvb_frontend device from the bus, optionally. Because I simply don't want to any new demod users for that callback unless needed for some strange reason. Disabling demod TS IF is also power-management issue. I didn't made any measurement how much current it will leak if any when left active on sleep, but it could do that. Also as that callback is almost 100% currently used by bridge drivers, I don't want start using it for demods too. As you could see from em28xx case there is now situation it will not be called at all. It was added by you by commit ba7e6f3e3e639de2597afffaae3fda75f6e6082d V4L/DVB (4665): Add frontend structure callback for bus acquisition. This patch enables generic bus arbitration callbacks enabling dvbcore frontend_open and frontend_release to pass 'acquire' and 'release' hardware messages back into the DVB bridge frameworks. Frameworks like cx88 can then implement single bus multiple demod card sharing features, which would prohibit two frontends from attempting to use a single transport bus at the same time. ... and commit message says it is aimed for bridge driver. regards 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On 07/20/2015 06:00 PM, Steven Toth wrote:
On Mon, Jul 20, 2015 at 10:30 AM, Antti Palosaari cr...@iki.fi wrote:
On 07/19/2015 01:21 AM, Steven Toth wrote:
http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275
Patches above are available for test.
Antti, note the change to SI2168 to add support for enabling and
disabling the SI2168 transport bus dynamically.
I've tested with a combo card, switching back and forward between QAM
and DVB-T, this works fine, just remember to select a different
frontend as we have two frontends on the same adapter,
adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2.
If any testers have the ATSC or DVB-T, I'd expect these to work
equally well, replease report feedback here.
That does not work. I added debug to see what it does and result is that
whole si2168_set_ts_mode() function is called only once - when frontend is
opened first time. I used dvbv5-scan.
That works very reliably for me, in the 4.2 rc kernel, when using
azap, tzap and dvbtraffic. They're v3 api's of course, but dvb-core
should take care of the differences. Specifically, dvb_frontend.c
dvb_frontend_open() and dvb_frontend_release().
With additional debug added, I clearly saw the syncronization and
acquiring and releasing (via ts_bus_control) of the bus, with each
demodulator.
I am not sure why you even want to that. Is it because of 2 demods are
connected to same TS bus? So you want disable always another? Or is is just
power-management, as leaving TS active leaks potentially some current.
Two demods are on the same bus, so we need to disable the non-active
demod, to ensure the active demodulator can correctly drive the
transport interface.
Anyway, if you want control TS as runtime why you just don't add TS disable
to si2168_sleep()? If you enable TS on si2168_init() then correct place to
disable it is si2168_sleep().
That's what dvb-core does, today in:
dvb_frontend_open()
if (dvbdev-users == -1 fe-ops.ts_bus_ctrl) {
if ((ret = fe-ops.ts_bus_ctrl(fe, 1)) 0)
goto err0;
and in dvb_frontend_release()...
if (fe-ops.ts_bus_ctrl)
fe-ops.ts_bus_ctrl(fe, 0);
The first user of the device ensures ts_bus_control is called when its
enabled, bring the demodulator on to the bus.
The last user of the device ensures ts_bus_control is called when the
device is no longer required.
Why build tristating mode control into the demod specific driver when
its been supported in the core for a long time?
It won't prevent multiple callers from opening two different frontends
(0/1) at the same time, but lack of shared resource management has
been the case on dvb-core (and v4l2) for quite a while.
If you have use case that isn't working, I'm happy to discuss.
Look at the em28xx driver and you will probably see why it does not work
as expected. For my eyes, according to em28xx driver, it looks like that
bus control is aimed for bridge driver. You or em28xx is wrong.
regards
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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Look at the em28xx driver and you will probably see why it does not work as expected. For my eyes, according to em28xx driver, it looks like that bus control is aimed for bridge driver. You or em28xx is wrong. Neither are wrong. In some cases the call needs to be intercepted by the frontend in order to disable its TS output. In other cases it needs to be intercepted by the bridge to control a MUX chip which dictates which demodulator's TS output to route from (typically by toggling a GPIO). 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Mon, Jul 20, 2015 at 12:06 PM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, I was not aware of the fact that your patch depends on dvb-core as in 4.2-RC2 (and up, I guess) I tested against 3.18.18 and 4.1.2. That might explain the failures. Anyhow, as soon as Antti and you are on the same page regarding this patch, I'll test again against a 4.2-RC1 Regards, Tycho. Thank you Tycho. I specifically only tested on 4.2, with the entire tree. No attempt was made to backport or otherwise test in environments outside on prior kernels. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com Op 20-07-15 om 15:13 schreef Steven Toth: On Sun, Jul 19, 2015 at 3:34 AM, Tycho Lürsen tycholur...@gmail.com wrote: Hi Steven, Tested your si2186 patch with my DVBSky T982 and TBS 6285 cards using European DVB-C Since MythTV can't handle multistandard frontends (yet), I've disabled DVB-T/T2 like this (I always do that): sed -i 's/SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A/SYS_DVBC_ANNEX_A/' drivers/media/dvb-frontends/si2168.c Result: both DVBSky T982 and TBS 6285 drivers are broken, meaning no lock, no tune. Regards, Tycho. Op 19-07-15 om 00:21 schreef Steven Toth: http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275 Patches above are available for test. Antti, note the change to SI2168 to add support for enabling and disabling the SI2168 transport bus dynamically. I've tested with a combo card, switching back and forward between QAM and DVB-T, this works fine, just remember to select a different frontend as we have two frontends on the same adapter, adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2. If any testers have the ATSC or DVB-T, I'd expect these to work equally well, replease report feedback here. Thanks, - Steve Interesting, although I'm slightly confused. My patch mere added the ability for dvb-core to tri-state the tsport out bus, similar to other digital demodulator drivers in the tree and testing with both azap and tzap (and dvbtraffic) showed no tuning, lock or other issues. What happens if you tzap/czap a known good frequency, before and after my patch, without your sed replacement, leaving T/T2 and A fully enabled? - Steve -- 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On 07/20/2015 07:45 PM, Devin Heitmueller wrote: Look at the em28xx driver and you will probably see why it does not work as expected. For my eyes, according to em28xx driver, it looks like that bus control is aimed for bridge driver. You or em28xx is wrong. Neither are wrong. In some cases the call needs to be intercepted by the frontend in order to disable its TS output. In other cases it needs to be intercepted by the bridge to control a MUX chip which dictates which demodulator's TS output to route from (typically by toggling a GPIO). Quickly looking the existing use cases and I found only lgdt3306a demod which uses that callback to control its TS interface. All the rest seems to be somehow more related to bridge driver, mostly changing bridge TS IF or leds etc. I don't simply see that correct solution for disabling demod TS IF - there is sleep() for this kind of things - and as I pointed out it does not even work for me em28xx based device because em28xx uses that routine to switch own TS mode. regards 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
On Mon, Jul 20, 2015 at 12:54 PM, Antti Palosaari cr...@iki.fi wrote: On 07/20/2015 07:45 PM, Devin Heitmueller wrote: Look at the em28xx driver and you will probably see why it does not work as expected. For my eyes, according to em28xx driver, it looks like that bus control is aimed for bridge driver. You or em28xx is wrong. Neither are wrong. In some cases the call needs to be intercepted by the frontend in order to disable its TS output. In other cases it needs to be intercepted by the bridge to control a MUX chip which dictates which demodulator's TS output to route from (typically by toggling a GPIO). Quickly looking the existing use cases and I found only lgdt3306a demod which uses that callback to control its TS interface. All the rest seems to be somehow more related to bridge driver, mostly changing bridge TS IF or leds etc. The API is flexible enough to be used by either the bridge intercepting the dvb_frontent_open operation, or by allowing the demodulator itself to act upon it. The API itself specifically describes the TS BUS CONTROL access, and whether something upstream of the demodulator wants a downstream device attached, or detached from the transport electrical interface. I see little point adding more bridge glue to route each dvb frontend into the cx23885-bridge and making a judgement based on the board type, when dvb-core is already effectively doing this, and has been for sometime. The caveat to this, is if you find a use-case that breaks the current driver in the current tip kernel. I currently do not see that. I don't simply see that correct solution for disabling demod TS IF - there is sleep() for this kind of things - and as I pointed out it does not even work for me em28xx based device because em28xx uses that routine to switch own TS mode. Asking a demodulator to sleep/wake is absolutely not the same thing as asking it to stop/start driving electrical signals on a bus. We can agree or disagree about whether a part should be tri-stated in init/sleep() and under what circumstances, but why bother when someone has gone to the trouble of declaring a perfectly good tr-state interface in dvb-core, taht automatically asserts and de-asserts any dvb_frontend device from the bus, optionally. -- Steven Toth - 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Hi Steven, Tested your si2186 patch with my DVBSky T982 and TBS 6285 cards using European DVB-C Since MythTV can't handle multistandard frontends (yet), I've disabled DVB-T/T2 like this (I always do that): sed -i 's/SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A/SYS_DVBC_ANNEX_A/' drivers/media/dvb-frontends/si2168.c Result: both DVBSky T982 and TBS 6285 drivers are broken, meaning no lock, no tune. Regards, Tycho. Op 19-07-15 om 00:21 schreef Steven Toth: http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275 Patches above are available for test. Antti, note the change to SI2168 to add support for enabling and disabling the SI2168 transport bus dynamically. I've tested with a combo card, switching back and forward between QAM and DVB-T, this works fine, just remember to select a different frontend as we have two frontends on the same adapter, adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2. If any testers have the ATSC or DVB-T, I'd expect these to work equally well, replease report feedback here. Thanks, - Steve -- 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: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Dear : Steven Wow .. I can't believe You are so quickly with professional service Thanks for your support . Very thanks Best Regards -Original Message- From: Steven Toth [mailto:st...@kernellabs.com] Sent: Sunday, July 19, 2015 6:22 AM To: to...@wincomm.com.tw; Antti Palosaari Cc: Linux-Media Subject: Adding support for three new Hauppauge HVR-1275 variants - testers reqd. http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275 Patches above are available for test. Antti, note the change to SI2168 to add support for enabling and disabling the SI2168 transport bus dynamically. I've tested with a combo card, switching back and forward between QAM and DVB-T, this works fine, just remember to select a different frontend as we have two frontends on the same adapter, adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2. If any testers have the ATSC or DVB-T, I'd expect these to work equally well, replease report feedback here. Thanks, - Steve -- Steven Toth - 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
Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
http://git.linuxtv.org/cgit.cgi/stoth/hvr1275.git/log/?h=hvr-1275 Patches above are available for test. Antti, note the change to SI2168 to add support for enabling and disabling the SI2168 transport bus dynamically. I've tested with a combo card, switching back and forward between QAM and DVB-T, this works fine, just remember to select a different frontend as we have two frontends on the same adapter, adapter0/frontend0 is QAM/8SVB, adapter0/frontend1 is DVB-T/T2. If any testers have the ATSC or DVB-T, I'd expect these to work equally well, replease report feedback here. Thanks, - Steve -- Steven Toth - 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
