Hi,
I've been thinking about the DMA approach. The problem I found out is that we
need to transfer all messages we're given at time in one DMA chain ... at
least
that's how I understand it from the FSL manual (see Fig. 27-10 in the mx28
manual).
I can't follow you: mxs_i2c_xfer() gets
Dear Wolfram Sang,
Hi,
I've been thinking about the DMA approach. The problem I found out is
that we need to transfer all messages we're given at time in one DMA
chain ... at least that's how I understand it from the FSL manual (see
Fig. 27-10 in the mx28 manual).
I can't follow
You can get a large list of i2c messages. In the current implementation, yes,
they're iterated in mxs_i2c_xfer_msg. Correct.
If you want to do DMA transfer do/from the i2c controller, you have to take
all
these messages and create the chain of DMA transfers according to these
Dear Wolfram Sang,
You can get a large list of i2c messages. In the current implementation,
yes, they're iterated in mxs_i2c_xfer_msg. Correct.
If you want to do DMA transfer do/from the i2c controller, you have to
take all these messages and create the chain of DMA transfers according
But then you don't have the DMA chain linked. Which I wonder if the
controller
has any problem with or not. I tried yesterday, got wrotes working perfectly,
but still had issues with reads, which is exactly what needs to be chained.
Yes, the read needs chaining of two DMA command blocks.
Hi Marek,
you forgot the most important list, linux-i2c ;)
I recently tried mxs-i2c (on 3.4-rc4) with at24 eeprom, didn't work as
expected.
Yes, we had the same this week/last week.
Apparently, there might be some timing issue, when I put printk() into the
at24
driver eeprom write
Dear Wolfram Sang,
Hi Marek,
you forgot the most important list, linux-i2c ;)
I recently tried mxs-i2c (on 3.4-rc4) with at24 eeprom, didn't work as
expected.
Yes, we had the same this week/last week.
Ah ok ;-)
Apparently, there might be some timing issue, when I put printk()
