i2c_gate_ctrl question

i2c_gate_ctrl question

[Steve Kerrison]

Hi media men & women,

I have a question regarding the cxd2820r I'm working on with a couple of
other people.

In my naivety I implemented i2c gate control for the device (to access
the tuner behind it) as a separate i2c device that did the passthrough.
Now that I realise this, it would make sense to use the gate_ctrl
features.

However, picking apart the USB data it looks as though the way the
cxd2820r implements "gate control" isn't immediately compatible with the
implementation seen in other devices.

Example, and I2C send to the tuner at (addr << 1) of:
{ xx, xx, ..., xx}

becomes a write to (demod_addr << 1) of :
{ 09, (addr << 1) | flags, xx, xx, ..., xx}

And an i2c receive is implemented to a receive from the demod address,
not from the tuner address.

So, unless there are open and close gate commands that aren't apparent
from the snoop, or there's something I've missed, all i2c transfers to
the tuner have to be mangled - sorry I mean encapsulated - prior to
sending. To my understanding this doesn't fit in with the gate_ctrl
implementation for i2c.

I haven't had time to examine all other gate control implementations in
the media modules, so if anyone knows any good examples that might work
in a similar way, I'd appreciate the tip-off. Otherwise, would there be
any objections to my implementation of a dummy i2c device that does the
encapsulation?

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

Re: i2c_gate_ctrl question

[adq]

On 7 March 2011 09:52, Steve Kerrison <steve@stevekerrison.com> wrote:
> Hi media men & women,
>
> I have a question regarding the cxd2820r I'm working on with a couple of
> other people.
>
> In my naivety I implemented i2c gate control for the device (to access
> the tuner behind it) as a separate i2c device that did the passthrough.
> Now that I realise this, it would make sense to use the gate_ctrl
> features.
>
> However, picking apart the USB data it looks as though the way the
> cxd2820r implements "gate control" isn't immediately compatible with the
> implementation seen in other devices.
>
> Example, and I2C send to the tuner at (addr << 1) of:
> { xx, xx, ..., xx}
>
> becomes a write to (demod_addr << 1) of :
> { 09, (addr << 1) | flags, xx, xx, ..., xx}
>
> And an i2c receive is implemented to a receive from the demod address,
> not from the tuner address.
>
> So, unless there are open and close gate commands that aren't apparent
> from the snoop, or there's something I've missed, all i2c transfers to
> the tuner have to be mangled - sorry I mean encapsulated - prior to
> sending. To my understanding this doesn't fit in with the gate_ctrl
> implementation for i2c.
>
> I haven't had time to examine all other gate control implementations in
> the media modules, so if anyone knows any good examples that might work
> in a similar way, I'd appreciate the tip-off. Otherwise, would there be
> any objections to my implementation of a dummy i2c device that does the
> encapsulation?

Yup, it sounds like the gate_ctrl code won't work in this case and
you'll need a seperate i2c bus.

An example is the cx24123 demod, which creates its own i2c tuner bus.