On Mon, Jul 20, 2015 at 12:54 PM, Antti Palosaari <crope@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
