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

[Antti Palosaari <crope@iki.fi>]

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/