On 07/20/2015 06:00 PM, Steven Toth wrote:
On Mon, Jul 20, 2015 at 10:30 AM, Antti Palosaari <crope@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
