[i2c] [patch 126.96.36.199, version 4] add support for the PCF8575 chip
david-b at pacbell.net
Wed Oct 31 00:25:54 CET 2007
On Tuesday 30 October 2007, Jean Delvare wrote:
> > In terms of the driver I posted ... if that matters, the setup()
> > method can set up the state for each signal. That's essentially
> > how all pcf857x drivers act. (I'm also thinking about adding a
> > field to the platform data with an intitialization value.)
> Except that you can't initialize *each* signal with the PCF847x chips,
> you have to initialize them all at once. I was wondering how the GPIO
> framework deals with this... if it does.
Exactly why the version of this driver I posted to LKML yesterday
includes a software version of the latch! That way when something
gets written, all the other bits can have been initialized to an
"as expected" value, rather than the "all inputs, as from reset"
value the version I posted here was using.
> > > The pcf8574 and pcf8575 drivers have a sysfs interface, and we
> > > can't replace them with something that doesn't offer an equivalent
> > > interface.
> > As I mentioned, that's never been an issue on any of the boards
> > I've worked with. An either/or approach would be fine .. either
> > use the driver exposing in-kernel capability, or don't. (And in
> > that case, one could offer a sysfs interface instead.)
> Well, in the long run, I'd like to avoid having 3 drivers to maintain
> if we can do the same with just one. But I'm fine having 3 drivers for
It seems to be the best way forward for the moment. At least
it'd provide a clear target for eliminating some code.
> > > Another problem is that not everyone uses these chips on embedded
> > > designs. Some users simply connect them to regular PCs (for example
> > > using an I2C-over-parport adapter), so you don't have any platform code
> > > to declare the chips.
> > As you know, i2c_board_info for a chip can be provided by code
> > that runs much later than system boot ("platform code").
> Yes but it doesn't help in this case: each user is different and has its
> own hardware setup and would need its own code. You can't tell users to
> go write their own kernel code.
It surely depends what sort of "user" you're talking about!
Plus, when the plug-in assembly is a complex of components, the
driver for that assembly is going to need to know how to configure
more than just this particular chip.
I suspect that in some simple cases there's no reason a configfs
based thing couldn't be written to take userspace instructions about
how to do various things. Folk using embedded products won't care
much about it, but people doing one-off prototypes (maybe from a PC)
would be able to use it just fine.
> > > Thus, if the replacement driver is a new-style
> > > driver, we'll need a way to declare I2C devices from user-space. I have
> > > an idea how this would be done, but I couldn't find the time to
> > > implement it yet.
> > That may be true, but user-space chip declaration is a separate
> > issue from whether the driver is a new-style one or not.
> In the current state, it is not a separate issue, because you can
> instantiate a device at an arbitrary address from user-space with
> legacy drivers (using module parameters) while you can't instantiate a
> device at an arbitrary address from user-space with new-style drivers.
It's a separate issue in the sense that such capabilities are not
part of the standard Linux driver model.
To the extent that you're focussing on transitioning legacy I2C
models into the future, it's an issue ... but I'd still call it a
separate issue from having a smoothly functioning driver framework.
Both in the technical sense (it can/should be layered over core
driver infrastructure) and in the sense of a user model (it'd be
more or less specific to I2C, and maybe even to specific devices).
> > And in fact it's a complete non-issue when the chip is being used
> > to control behavior of kernel drivers ... user-space declaration
> > in those cases at best a non-goal.
> Agreed - but that's not what I was meaning to discuss here.
Good enough. So long as there's a straightforward interface
for kernel code to twiddle bits -- I think the GPIO interfaces
are the best fit for that -- I'll be happy, and won't object
to optional mechanisms for userspace.
More information about the i2c