> I don't know how to do an async i2c driver.

Queue transfer descriptors in a linked list and have the i2c interrupt
service them, in queue order, calling a callback when each is completed.
Yes, it must be interrupt based.

I guess it's just the codec i2c driver on AMS that is like that. On i.MX31
it's the serial driver.

IMO, the simplest is to
> do not too much in the interrupt itself. Hence the interrupt in my
> proposal just wakes up a thread that does the actual work.

It's not the cheapest if the other way is possible. Threads have a pretty
large structure and the required stack to go with it.

> On the AMS targets, i2c to the fm tuner is done by "bit-banging"
> (GPIO toggling) using udelays to do the timing. Can you do async
> with that?

Forgot about that. A pity but no, that's out of the question.

> The idea is that the fm tuner driver knows when a channel is switched,
> tuner is powered off or on, etc. You can't just re-read it, because we
> want fresh data from the current station.

I think that's basically what I meant-- clear it when someone messes with
the tuner in certain ways but push that up to any UI so it can keep in sync.

Mike
Received on 2011-11-06