On 7 March 2011 09:52, Steve Kerrison <steve@xxxxxxxxxxxxxxxxx> 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.
--
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
