public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Antti Palosaari <crope@iki.fi>
To: Steven Toth <stoth@kernellabs.com>
Cc: tonyc@wincomm.com.tw, Linux-Media <linux-media@vger.kernel.org>
Subject: Re: Adding support for three new Hauppauge HVR-1275 variants - testers reqd.
Date: Mon, 20 Jul 2015 19:35:26 +0300	[thread overview]
Message-ID: <55AD234E.5010904@iki.fi> (raw)
In-Reply-To: <CALzAhNVFBgEBJ8448h1WL3iDZ4zkR_k5And0-mtJ6vu97RZLTQ@mail.gmail.com>

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/

  reply	other threads:[~2015-07-20 16:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-18 22:21 Adding support for three new Hauppauge HVR-1275 variants - testers reqd Steven Toth
2015-07-19  7:34 ` Tycho Lürsen
2015-07-20 13:13   ` Steven Toth
2015-07-20 16:06     ` Tycho Lürsen
2015-07-20 16:32       ` Steven Toth
2015-07-21 16:11         ` Tycho Lürsen
2015-07-21 16:19           ` Steven Toth
2015-07-21 18:07             ` Tycho Lürsen
2015-07-21 18:59               ` Tycho Lürsen
2015-07-21 19:02                 ` Steven Toth
2015-07-21 19:21                   ` Tycho Lürsen
2015-07-21 19:00               ` Steven Toth
2015-07-21 21:33                 ` Tycho Lürsen
2015-07-22  7:15                 ` Tycho Lürsen
2015-07-22 12:55                   ` Steven Toth
2015-07-22 17:44                     ` Tycho Lürsen
2015-07-24 13:38                       ` Steven Toth
2015-07-20  0:52 ` Tony Chang(Wincomm)
     [not found] ` <1454427BAA91444C85615ABB9382A2DE@wincomm.com.tw>
2015-07-20 12:38   ` Steven Toth
2015-07-20 14:30 ` Antti Palosaari
2015-07-20 15:00   ` Steven Toth
2015-07-20 16:35     ` Antti Palosaari [this message]
2015-07-20 16:45       ` Devin Heitmueller
2015-07-20 16:54         ` Antti Palosaari
2015-07-20 17:14           ` Steven Toth
2015-07-20 17:28             ` Antti Palosaari
2015-07-20 19:04               ` Steven Toth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55AD234E.5010904@iki.fi \
    --to=crope@iki.fi \
    --cc=linux-media@vger.kernel.org \
    --cc=stoth@kernellabs.com \
    --cc=tonyc@wincomm.com.tw \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox