On Mon, Mar 10, 2014 at 10:29:02PM +0100, Hans de Goede wrote: > >> Is this bus similar enough to i2c that we can use the i2c subsys > >> for this, maybe with an extra controller flag, or do we need to > >> likely write a whole new subsys for this ? > > > > It really looks like I2C, except that at the end of each byte > > sent, there's an extra parity bit sent. I think we don't really > > need a new bus for this, but we can somehow fit this into I2C. We > > could do it through an extra controller flag, but I'm not sure > > that it's actually needed, since we can handle the parity bit in > > the driver and present a 8-bit interface to the framework. > > Sounds good (better then writing our own subsys). About the extra > controller flag, that would be to opt-out of drivers which do > auto bus scanning, as well as maybe to opt out of the creation > of i2c-dev /dev nodes. As we're not really i2c and we may want > to avoid userspace from poking the bus. > > Anyways first we need to learn more about this.
Actually, I spoke a bit too quickly.
After spending some time on this yesterday, this is what I understood:
It's similar to I2C (and even more SMBUS) in many points:
- It's using SDA and SCL
- It starts with a start condition, that is SDA beind pulled down
while SCL is high.
- the master always handles SCL, and either the master or the device
handles SDA, depending on the direction.
- Whenever the transaction is done, the master will issue a stop
condition
However, it also differs by some aspects:
- It's a point to point bus, you can only have one device.
- Once the start condition is issued, you transmit a direction bit,
then the register address on the device on 8 bits, then 1 bit of
parity. Then the device will ack it, and the communication goes
on, either sending or receiving data, depending on the direction.
- Whenever you're writing, the ACK flag is only sent at the end of
the transaction by the device, to acknowledge the fact that it
received properly both the address and the data to write.
- Whenever you're reading, there's no ACK involved. If there's some
kind of error (invalid address for example), the device will just
pull SDA up for the whole 9 clock cycles (8 bits of data +
parity). Since the parity check will be wrong, the master will now
something wrong happened.
So a standard communication on this bus will be:
Writing:
+-------+-------+--------------+------------+----------+------------+---------+------+
| Start | 0 (m) | Register (m) | Parity (m) | Data (m) | Parity (m) | ACK (s) |
Stop |
+-------+-------+--------------+------------+----------+------------+---------+------+
Reading:
+-------+-------+--------------+------------+----------+------------+------+
| Start | 1 (m) | Register (m) | Parity (m) | Data (s) | Parity (s) | Stop |
+-------+-------+--------------+------------+----------+------------+------+
There's still some subtleties I don't get yet, but the more I think
about this, the more I feel like we'll have to write our own bus :(
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
