Subject: Re: New i2c framework
To: Jason Thorpe <email@example.com>
From: Eduardo Horvath <eeh@NetBSD.ORG>
Date: 07/31/2003 21:12:06
On Thu, Jul 31, 2003 at 09:01:08AM -0700, Jason Thorpe wrote:
> On Thursday, July 31, 2003, at 08:43 AM, Eduardo Horvath wrote:
> >But they are separate address spaces, so don't you need some way to
> >differentiate between communications to a 7-bit device or a 10-bit
> >device at the same address?
> I need to reread the I2C spec before I can answer this question.
> >Huh? How does that prevent you from doing direct configuration?
> Direct configuration requires being able to deterministically identify
> a device based on some unique cookie. I2C does not have that.
> Chris's suggestion of a hybrid approach using a platform-specific table
> could be useful, but pure direct configuration like is possible on e.g.
> SBus or PCI is simply not possible on I2C.
> >So... How does a userland program issue commands that require
> >repeated starts?
> With regard to more complex operations being directed by userspace,
> I've been toying with the idea of a "scripted" API that userland could
> use (I actually implemented a "scripted" API for kernel drivers
> originally, but it was a bit too complicated to use :-)
> In any case, I don't want to gate this on the userland API. I consider
> that piece a moving target at this point, and it really has no direct
> bearing on the API used within the kernel.
If we do eventually move to a scripted API (which is the right way to
go IMHO [think SCSI]) it would be best if we had it at the beginning
rather than generating flag days later on.