-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
On 03/11/2014 10:21 AM, Maxime Ripard wrote: > 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 :( So on the bus things are different then with i2c, that does not mean we cannot still pretend it is i2c to upper layers in the kernel. I still believe we should try to make this some kind of pseudo i2c controller and not do a new bus for this. If you look at the axp209 code intended for upstream then it uses a lot of i2c infra, not just the bus stuff, but also things like devm_regmap_init_i2c, so if we do our own bus we would need to write out own regamp glue for that bus too. And if we try and fail we can always define our own bus for this later. Regards, Hans -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMe4msACgkQF3VEtJrzE/vtDACeMZ7PalYqGhD53Pje4FS5hGIh MVQAmgOGVtuM0Hba46UlI4v7UQs+jNEf =smP1 -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
