-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi Simon,
On 15.12.2015 19:58, Simon Glass wrote:
Hi Matheusz,
On 10 December 2015 at 14:41, Mateusz Kulikowski mateusz.kulikowski@gmail.com wrote:
[...]
+/**
- struct dm_spmi_ops - SPMI device I/O interface
- Should be implemented by UCLASS_SPMI device drivers. The standard
- device operations provides the I/O interface for it's childs.
- @read: read register
- @write: write register
You should describe the args also.
OK
What is different between this and I2C? Could you use that uclass? It seems to have an additional address value (pid)- is that right?
That's a difficult question, as my knowledge about this bus is based only on drivers/SoC documentation/speculation (bus spec is not public :()
At wiring level it looks exactly like multi-master I2C On logical level: - - Each bus can have several slaves (up to 16). - - Each slave can have several peripherals (up to 256), - - Each peripheral can have up to 256 registers (I think each is 8-bit wide). - - Each peripheral have 2 ID registers (type/subtype) that can be used for probing
PM8916 implements two slaves (but for some reason in Linux they are presented as 2 sibling nodes on SPMI bus).
But this is device perspective.
On SoC side, implementation is different and I fully don't understand all rationale behind it.
SoC has some kind of arbiter with 127 channels (2x - separate for reads called "observers" and separate for writers).
Each peripheral (not slave) has assigned single channel that I have to map in probe(). This means that (as far as I understand) there can be no more than 127 peripherals on single bus.
Weird think is that while doing reads/writes I have to use not only channel #, but also full slave/peripheral/register address.
Perhaps my driver oversimplified SPMI, or maybe SPMI is just I2C, using some simple protocol to charge royalty fees ;)
If you do end up with a new uclass, please add a sandbox driver for it and a test.
OK
Thanks, Mateusz