Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[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

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

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
>

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Steven Toth]

On Sun, Jul 19, 2015 at 3:34 AM, Tycho Lürsen <tycholursen@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

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

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-RC>1
Regards,
Tycho.

Op 20-07-15 om 15:13 schreef Steven Toth:
> On Sun, Jul 19, 2015 at 3:34 AM, Tycho Lürsen <tycholursen@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
>

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Steven Toth]

On Mon, Jul 20, 2015 at 12:06 PM, Tycho Lürsen <tycholursen@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-RC>1
> 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 <tycholursen@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
>>
>

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

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 <tycholursen@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-RC>1
>> 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
>

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Steven Toth]

On Tue, Jul 21, 2015 at 12:11 PM, Tycho Lürsen <tycholursen@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

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[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 <tycholursen@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.

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

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 
>> <tycholursen@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

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Steven Toth]

On Tue, Jul 21, 2015 at 2:59 PM, Tycho Lürsen <tycholursen@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 <tycholursen@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

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

Op 21-07-15 om 21:02 schreef Steven Toth:
> On Tue, Jul 21, 2015 at 2:59 PM, Tycho Lürsen <tycholursen@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 <tycholursen@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.

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Steven Toth]

On Tue, Jul 21, 2015 at 2:07 PM, Tycho Lürsen <tycholursen@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 <tycholursen@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

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

Op 21-07-15 om 21:00 schreef Steven Toth:
> On Tue, Jul 21, 2015 at 2:07 PM, Tycho Lürsen <tycholursen@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 <tycholursen@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.

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

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 <tycholursen@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 <tycholursen@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.
>

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Steven Toth]

On Wed, Jul 22, 2015 at 3:15 AM, Tycho Lürsen <tycholursen@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

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tycho Lürsen]

Op 22-07-15 om 14:55 schreef Steven Toth:
> On Wed, Jul 22, 2015 at 3:15 AM, Tycho Lürsen <tycholursen@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.

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Steven Toth]

>> 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

RE: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Tony Chang(Wincomm)]

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:stoth@kernellabs.com] 
Sent: Sunday, July 19, 2015 6:22 AM
To: tonyc@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

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Steven Toth]

On Mon, Jul 20, 2015 at 2:00 AM, Tony Chang(Wincomm)
<tonyc@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

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Antti Palosaari]

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/

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Steven Toth]

On Mon, Jul 20, 2015 at 10:30 AM, Antti Palosaari <crope@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

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Antti Palosaari]

On 07/20/2015 06:00 PM, Steven Toth wrote:
> On Mon, Jul 20, 2015 at 10:30 AM, Antti Palosaari <crope@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/

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Devin Heitmueller]

> 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

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Antti Palosaari]

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/

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Steven Toth]

On Mon, Jul 20, 2015 at 12:54 PM, Antti Palosaari <crope@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

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Antti Palosaari]

On 07/20/2015 08:14 PM, Steven Toth wrote:
> On Mon, Jul 20, 2015 at 12:54 PM, Antti Palosaari <crope@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/

Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.

[Steven Toth]

>> 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