03 дек. 2014 г., в 22:38, Felipe Balbi <balbi@xxxxxx> написал(а):
> then handle slave interrupts :-) But handle them so that it won't race
> with a master transfer request. Moving omap_i2c_xfer() inside the IRQ
> handler isn't the best way to do it, however.
I do that with care :)
Currently, only 'resize fifo' and 'clear fifo' is the one thing what must
be moved into ISR (I'll check is it possible or late).
Because I can't ask ISR to generate interrupt to start master transfer.
I thought about that without luck.
I have to write to CON register. I can lock xfer for short time to
check STAT (for AAS) and either write CON or flag to start master after
slave complete.
'clear fifo' must be done in response to NACK. TRM states this[1]"
"TX and RX FIFOs must be cleared (the I2Ci.I2C_BUF[6] TXFIFO_CLR
and I2Ci.I2C_BUF[14] RXFIFO_CLR bits are set to 1)."
'resize fifo' could be avoided at all, but, it so nice feature.
And yes, if we could utilize full fifo to send message, we could set
threshold to message size and get only RRDY at the end.
If message size is greater than fifo size, we want to use double
buffer scheme to minimize ISR latencies.
But now, variable 'fifo_size' is set to half of IP real fifo size.
And for messages with fifo_size/2 ... fifo_size we use drainig
feature (get RDR, XRD). While we could receive only one IRQ.
I'll fix that.
>> And, I'll try to move fifo threshold init code into ISR. Don't see
>> something wrong.
>
> I wouldn't do that. It's just too late... look, IRQs won't fire until
> I2C_CON is setup to start a transfer (transmit or receive), you *must*
> resize FIFO before starting a transfer otherwise, well, you know...
Looks, like RRDY is fired after simple compare with threshold.
I'll check is this possible (but, that doesn't cover into TRM).
Or may be it is late to change it.
[1] AM-DM37x Multimedia Device Silicon Revision 1.x - sprugn4r,
p. 2796, Table 17-9. HS I2C Interrupt Events--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
