Sonasath, Moiz had written, on 07/15/2009 05:37 PM, the following:
>
> -----Original Message-----
> From: Menon, Nishanth
> Sent: Wednesday, July 15, 2009 5:32 PM
please stop top posting..
>> Sonasath, Moiz had written, on 07/15/2009 05:29 PM, the following:
>> I am also not sure, if the count=100; value will be enough time for
the XUDF
>> > to be set. If not then it will keep running into timeout errors.
>> Do you mean we need a delay for checking again? that should be easy to
>> incorporate - what kind of delay are we speaking of here? do you
have a
>> count requirement for handling this? it is essentially the time b/w
XRDY
>> to XUNDF.. this should be deterministic rt?
>>
>
> AFAIK, the time between XRDY/XDR and setting of XUDF bit is not
>deterministic, it depends on the I2C bus speed but I am not sure if we
>can translate the speed into a fixed count number which we can use as a
> timeout limit. In that case we need to make a balanced assumption of
>the count value so that we don't fall in the timeout case under normal
>operation.
>
> May be someone can give a pointer here.
>
Here is my attempt at this:
XRDY -> in this case the FIFO is completely empty - fill it up for XTRSH
XDR -> FIFO is not completely empty, fill as per TXSTAT reg.
if you look at the sequences of events that should happen ->
a) no previous data transmitted: XRDY, XUNDF
b) previous data available, XDR, XRDY, XUNDF
The variables are:
i) bus speed
ii) num bytes to empty (if XRDY then 0, else TXSTAT)
Time = (num_bytes+c) * (1/bus_speed)
where c = some constant time interval for XRDY->XUNDF.. I think..
One possible strategy:
a)Worst case is XTRSH, so, Compute time prior to entry into transmit
loop. Set the count as this+ add a constant for additional events
b) Add a constant delay when you decide to continue back - not sure if
cpu_relax is predictable delay..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
