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
