Jean Delvare wrote:
>>> Michael, do you still need this for i2c-algo-bit? We did not discuss
>>> this again recently, so I admit I don't know what is the status of this
>>> request.
>>>
>> Jean,
>>
>> Yes, the problem still exists, and I still need a way to lock the i2c
>> adapter during certain volitile operations at driver start-up.
>>
>> Right now I have an artificial delay in place as a workaround, but
>> that's only because there currently is no other choice.
>>
>
> I'm really sorry. As you didn't come back to me about this issue, I
> wrongly assumed that you had solved it in another way and you were no
> longer interested in adding these hooks to i2c-algo-bit. If you still
> need it then let's get this sorted out.
>
It's not my top priority right now. I have been able to work around the
issue by sacrificing efficiency, although a real fix would be better for
the long run.
>> Basically, I have a single piece of silicon that is capable of bringing
>> down the entire i2c bus if somebody attempts to communicate with any
>> other IC during initialization of this silicon.
>>
>
> Can you clarify your requirements? I'm not sure I understand exactly
> what you need. Do you need exclusive access to the I2C bus for a number
> of transactions? Or do you need exclusive access to the I2C bus for an
> arbitrary period of time? Or do you need to block access to the I2C bus
> entirely? How do you know when to start the blackout period, and when
> to end it?
>
> We have to design a new mechanism so I would like to make sure that
> whatever I come up with, fits at least your needs and those of David.
I need to block access to the i2c bus for the duration of a long series
of i2c_transfer calls from anybody other than the client module
currently being initialized.
Basically, I have an i2c client that must not be interrupted during
initialization of the part. I need to be able to implement the
following behavior (in pseudocode)
int crappychip_init() {
lock host adapter i2c bus -- if bus is already locked, then block
until it is unlocked.
do initialization (many calls to i2c_transfer)
unlock host adapter i2c bus.
}
...so I basically need the ability to host a mutex on the i2c adapter,
have a way for the i2c client to lock and unlock the mutex, and all
OTHER i2c clients on the bus must not be able to do i2c transactions
while the mutex is locked.
...but there is a gotcha -- the other i2c client drivers will not know
anything about the host adapter, nor will they know that they need to
use a locking mechanism before handling i2c transactions -- the locking
needs to be built-in to the host adapter's handling of i2c_transfer.
So, what I *really* need is for the i2c host adapter itself to lock or
unlock the i2c bus, based on a signal from a given i2c client module
that a series of i2c transactions are volatile and no other i2c traffic
is allowed until this long block of transactions are complete. The
"large blocks of transactions" can be a large series of multiple calls
to i2c_transfer, and can be directed to more than just one i2c address.
I think you made a suggestion a few months back, but I don't remember
exactly what you had in mind. One idea that I can think of is that the
i2c client module should request some uniquely generated id, and pass
this id into the call to i2c_transfer so that it knows that this
particular transaction is allowed to occur regardless of the state of
the lock on the i2c bus.
Making matters more complicated, the "do initialization" pseudocode part
above involves i2c transactions to two different IC's, but we must not
allow any communication to these IC's to occur other than the
transactions occurring in the "do initialization" sequence. ie, no
probing allowed during this time, not even probing of IC's being
initialized. The part being initialized is behind an i2c gate of
another part, and the i2c gate _must_ be closed after each i2c write and
opened before the next i2c write, due to a bug in the silicon.
I hope that describes the situation well enough -- Please let me know if
you need any clarification.
Regards,
Mike
_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c
