23.01.2015 12:45, Thierry Reding пишет:
On Thu, Jan 22, 2015 at 08:18:34PM +0300, Dmitry Osipenko wrote:
22.01.2015 19:06, Dmitry Osipenko пишет:
22.01.2015 18:22, Dmitry Osipenko пишет:
22.01.2015 10:55, Alexandre Courbot пишет:
On Thu, Jan 22, 2015 at 4:40 PM, Thierry Reding
<thierry.reding@xxxxxxxxx> wrote:
Should this not technically be le32_to_cpu() since the data originates
>from the I2C controller?
No, i2c_readl returns value in CPU endianness, so it's correct. But for
i2c_writel should be used le32_to_cpu(), since it takes value in CPU endianness.
It's my overlook, V2 is coming.
Why does this have to be initialized to 0 now?
I suspect this is because we are going to memcpy less than 4 bytes
into it, but I cannot figure out how that memcpy if guaranteed to
produce the expected result for both endiannesses.
That's correct. Memcpy is working with bytes, so it doesn't care about
endianness and produces expected result, since I2C message is char array.
I'll spend some more time reviewing, to see if nullifying should go as separate
patch.
Well, I2C_FIFO_STATUS returns 8-bit value. The rest of bits very likely to
be RAZ, however I don't see anything on it in documentation. In that case it
won't cause any problems with LE value and nullifying is only needed for BE
mode.
What does I2C_FIFO_STATUS have to do with anything?
My point was more that we already tell hardware how much data is to be
transferred (via the packet header in tegra_i2c_xfer_msg()), hence the
hardware shouldn't care whether the FIFO is padded with random data or
zeros.
Thierry
Got your point. I was thinking it's expected behavior, but now I'll elaborate
this more.
--
Dmitry
--
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
