Re: Locking inconsistencies in I2C land

--------
Warner Losh writes:

> Then I think that the whole request/release
> were added because that's holding the locks too long... 

That is one of my minor concerns:  There is no duration or length
limit on I2C transactions, so maybe the bus-lock should be
interruptible ?

> > For instance our shifting slave addresses one bit to the left, […]
>
> Yea... In hind sight, that was a big mistake way back when. I don't even
> recall why we did that now...  I kinda think it was that way when I started
> hacking on the stuff, but I don't recall now.

I suspect because the read/write bit is the LSB on the wire ?

> We do have half a dozen, at least, controllers
> that are used on modern gear. But dozens of i2c device drivers... what's
> the plan there? What did you have in mind?

My plan was that somebody else would respond to my email with
"I've been secretly working that for the last year and I'll be more
than happy to share what I've done" :-)

I can get us started by building a prototype on the Arm-based
T14sG6 I'm playing with, to the point where ACPI+TZ+HID works.

If we then decide to move on, I can find an intel-based SBC, and a
Rpi in my piles, and get them to work at the same level.

But that is probably as far as I can push this without help:  I
dont have the nerves to dive into DRM and I'm short on AMD-Zen
hardware to play with.

As for design, as much as I'm itching to design "The Perfect I²C
KAPI", I think it is prudent to keep the impedance between our KAPI
and Linux's KAPI minimal, but I have not studied their KAPI enough
to know how firmly we should tie ourselves to their mast.

It is not obvious to me if the reserve/release API should be
per bus or per slave.

ACPI code can access I2C directly now, but I did not see any
bus-locking primitives when I looked, and have not read if the spec
has language about it.  My guess is they presume exclusive access to
their slaves and thus only need non-contention on the bus/controller.

FDT have no similar "built in device drivers", so we can structure
our device drivers according to the locking model we pick.

SMBus support will probably be part of this project, but I have not
looked at it.

Poul-Henning

PS: That T14s is Qualcomm based, do we know of any friends at Qualcomm ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.