[U-Boot] [RFC PATCH 06/11] drivers: Add SPMI bus uclass

Mateusz Kulikowski mateusz.kulikowski at gmail.com
Thu Dec 17 00:09:54 CET 2015


-----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 at 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWce82AAoJELvtohmVtQzBLUIH/1NX6eAd+eh+HTTdntsni109
yQKMJVPEE17znTtcYgW2hpgWLqUa9aZ6n97hWMiWF7N+3879kWJYLTgj2uFBiVgl
nXS8DFdfE7BQlzwVrGLIoaIXC7Jx7w3O/+9k7XsTaU2QcX7E+rWjyj/Y88Uq8oen
M/MdtU2eYY/SggdMd99dEn305LrhRpXhDx0qgPTwGGb7BPwB2Vfrvm7mUrXMGTTY
GMbiKsNuiYzNdXGz65gmZ6fHHQM6Gmm5Lh5GYftMnn0qQA6D8PcDm8h+it1eqoW3
t1VpCmCp7k6eGzM6m+scwFHu0mCeGeYhYD+vRZIbxX0lu5UWIUuakVdjpJmn9Ig=
=iZjm
-----END PGP SIGNATURE-----


More information about the U-Boot mailing list