[i2c] [patch 188.8.131.52, version 4] add support for the PCF8575 chip
david-b at pacbell.net
Sun Oct 28 18:14:35 CET 2007
On Sunday 28 October 2007, Jean Delvare wrote:
> Hi David,
> I'm all for integrating the PCF8574 and PCF8575 support into the
> standard GPIO framework using a new-style driver. I have a number of
> questions though:
> * Can this framework deal with unknown states? The input/output state
> of the pins can't be read from these chips.
As you note, the issue is a hardware design condundrum. When chip
specs are reduced to calling something "pseudo-bidirectional" you
know there's got to be something odd happening...
The framework deals with that as follows: GPIO state is undefined
until it's been initialized as an input or output.
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.)
> * What kind of user-space interface does the GPIO framework offer, if
Nobody has written a layer adding that kind of capability, though
some folk have asked about one. It wouldn't be core functionality,
of course. One of several issues is how to know which signals are
safe to expose (in the sense that diddling values from userspace
won't break drivers that want to manage them from the kernel).
> The pcf8574 and pcf8575 drivers have a sysfs interface, and we
> can't replace them with something that doesn't offer an equivalent
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.)
> 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").
> 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.
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.
More information about the i2c