[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-video
Subject:    Re: Odd I2c gate code in tda1004x.c
From:       Andrew de Quincey <adq_dvb () lidskialf ! net>
Date:       2006-10-04 23:17:07
Message-ID: 200610050017.08040.adq_dvb () lidskialf ! net
[Download RAW message or body]

On Wednesday 04 October 2006 23:40, Hartmut Hackmann wrote:
> Hi, Andrew
>
> Thanks for the quick reply.
>
> Andrew de Quincey wrote:
> > On Wednesday 04 October 2006 22:28, Hartmut Hackmann wrote:
> >>Hi,
> >>
> >>I stumbled over some strange code in the tda1004x_set_fe()
> >>function. It calls the set_params() function without
> >>opening the gate before but afterwards it closes it.
> >>So
> >>- the set_params() function needs to open the gate before
> >>   it accesses the tuner, but it doesn't need to close it.
> >>- _init and _sleep need to do both.
> >>
> >>This is confusing. Is there a reason why it is this way?
> >>I would prefer either to completely control the gate
> >>in the  tda1004x_set_fe() function or completely leave
> >>it to the board specific code.
> >
> > The idea was to allow board specific code to override the default
> > i2c_gate_ctrl op provided by the demodulator if a board has some /other/
> > gate mechanism on it. So a board driver can just override that op once
> > and then doesn't need to care afterwards; it'll all happen automatically.
>
> That's clear. It is the function pointer you added.
>
> > Some gates (e.g. stv0299) auto-close after each i2c transaction. Since we
> > were trying to separate the pll code from the frontend code and the board
> > drivers themselves, the frontend doesn't know what the pll/tuner code is
> > going to do.. it could do several transactions, each requring the gate to
> > be opened each time. Therefore, it has to be up to the pll/tuner code to
> > open the gate if/when it needs to.
> >
> > Finally, the reason the frontend closes it after the call was simply to
> > ensure the the gate was definitely closed afterwards, if the gate happens
> > to be of the type which doesn't auto-close.
>
> This was the info i was missing! This also explains why you added the open
> call before each tuner transaction.
>
> So things should remain as they are. I just wanted to know ;-)

Cool - glad you agree :)

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
[prev in list] [next in list] [prev in thread] [next in thread]