[patch 2.6.26] gpio: pcf857x handle pca9500 and pca9501

[patch 2.6.26] gpio: pcf857x handle pca9500 and pca9501

[Jonathan Cameron]

From: Jonathan Cameron <jic23@cam.ac.uk>
Addition of pca9500 and pca9501 chips to the pcf857x driver.

Signed-off-by: Jonathan Cameron <jic23@cam.ac.u>
--
These two chips have two elements (on different i2c addresses), the first is a clone
of the pcf8574 and the second 2kBit eeprom. Seems easiest to support these separately
so main query about this patch is should the device naming reflect this dual
functionality. 

I've been using the pcf857x driver with a 9500 for several months without problems and
just want this in to clean up a confusing element in a board config.

As the Kconfig title for these is getting a bit long and the datasheet for these starts
with stating they are pcf957x compatible so I haven't changed it.
--
diff -uprN -X a/Documentation/dontdiff a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
--- a/drivers/gpio/Kconfig	2008-07-24 16:55:57.000000000 +0100
+++ b/drivers/gpio/Kconfig	2008-07-24 16:51:45.000000000 +0100
@@ -54,6 +54,7 @@ config GPIO_PCF857X
 	  some of them.  Compatible models include:
 
 	  8 bits:   pcf8574, pcf8574a, pca8574, pca8574a,
+	    	    pca9500, pca9501,
 	            pca9670, pca9672, pca9674, pca9674a,
 	  	    max7328, max7329
 
diff -uprN -X a/Documentation/dontdiff a/drivers/gpio/pcf857x.c b/drivers/gpio/pcf857x.c
--- a/drivers/gpio/pcf857x.c	2008-07-24 16:55:57.000000000 +0100
+++ b/drivers/gpio/pcf857x.c	2008-07-24 16:56:51.000000000 +0100
@@ -29,6 +29,8 @@
 static const struct i2c_device_id pcf857x_id[] = {
 	{ "pcf8574", 8 },
 	{ "pca8574", 8 },
+	{ "pca9500", 8 },
+	{ "pca9501", 8 },
 	{ "pca9670", 8 },
 	{ "pca9672", 8 },
 	{ "pca9674", 8 },
@@ -44,9 +46,9 @@ static const struct i2c_device_id pcf857
 MODULE_DEVICE_TABLE(i2c, pcf857x_id);
 
 /*
- * The pcf857x, pca857x, and pca967x chips only expose one read and one
- * write register.  Writing a "one" bit (to match the reset state) lets
- * that pin be used as an input; it's not an open-drain model, but acts
+ * The pcf857x, pca857x, pca950x and pca967x chips only expose one read
+ * and one write register.  Writing a "one" bit (to match the reset state)
+ * lets that pin be used as an input; it's not an open-drain model, but acts
  * a bit like one.  This is described as "quasi-bidirectional"; read the
  * chip documentation for details.
  *

Re: [patch 2.6.26] gpio: pcf857x handle pca9500 and pca9501

[David Brownell]

On Thursday 24 July 2008, Jonathan Cameron wrote:
> These two chips have two elements (on different i2c addresses),
> the first is a clone of the pcf8574 and the second 2kBit eeprom.

That is, NXP documents say it's a pcf8582 eeprom, which
is software-compatible with what Linux calls a 24c02 chip.

It'd be worth sending a patch so drivers/i2c/chips/at24.c
can handle those EEPROMs ...


> Seems easiest to support these separately so main query about
> this patch is should the device naming reflect this dual 
> functionality. 
> 
> I've been using the pcf857x driver with a 9500 for several
> months without problems and just want this in to clean up
> a confusing element in a board config. 

Hmm, well I don't really see a way around having two entries
in the relevant boards' i2c board info ... so this patch just
ensures that *one* entry can list the actual part.

I'm curious why you added this chp to the pcf857x driver
rather than to the at24 driver ... since it's quite obvious
from docs that the chip is pcf8574-compatible, but only the
pca9500 lists the EEPROM compatibility.

I guess given my druthers I'd update Kconfig for both drivers
to mention these parts (and their need for two drivers), plus
add them to the at24 driver (rather than pcf857x) purely because
the docs are, overall, more clear about the GPIO compatibility
than about the EEPROM.

- Dave

 
> As the Kconfig title for these is getting a bit long and the
> datasheet for these starts with stating they are pcf957x
> compatible so I haven't changed it. 

Right; helptext can have a sentence.

Re: [patch 2.6.26] gpio: pcf857x handle pca9500 and pca9501

[Jonathan Cameron]

Dear David,
> On Thursday 24 July 2008, Jonathan Cameron wrote:
>   
>> These two chips have two elements (on different i2c addresses),
>> the first is a clone of the pcf8574 and the second 2kBit eeprom.
>>     
>
> That is, NXP documents say it's a pcf8582 eeprom, which
> is software-compatible with what Linux calls a 24c02 chip.
>
> It'd be worth sending a patch so drivers/i2c/chips/at24.c
> can handle those EEPROMs ...
>   
Thanks, hadn't realized that it was compatible with that driver.
Given the approach that seems to have been taken there, is it not
the case that the changes should all be in the board config anyway
to support a new chip? As the board config in question isn't going
to be in mainline for a while anyway (awaiting da9030 driver) this
means that no such patch would be needed.
>> Seems easiest to support these separately so main query about
>> this patch is should the device naming reflect this dual 
>> functionality. 
>>
>> I've been using the pcf857x driver with a 9500 for several
>> months without problems and just want this in to clean up
>> a confusing element in a board config. 
>>     
>
> Hmm, well I don't really see a way around having two entries
> in the relevant boards' i2c board info ... so this patch just
> ensures that *one* entry can list the actual part.
>   
Indeed, I was merely advocating listing the actual part number so that
the board config corresponds to the chips in front of the person using it.
Not exactly important though as a comment explaining what is going on
will do instead.
> I'm curious why you added this chp to the pcf857x driver
> rather than to the at24 driver ... since it's quite obvious
> from docs that the chip is pcf8574-compatible, but only the
> pca9500 lists the EEPROM compatibility.
>   
Sorry, simply wasn't aware that the at24 driver would work with it
and am currently running 2.6.26 meaning it wasn't actually there.
I'm cynical and tend to wait for a release candidate or two before
moving to a new kernel series!
> I guess given my druthers I'd update Kconfig for both drivers
> to mention these parts (and their need for two drivers), plus
> add them to the at24 driver (rather than pcf857x) purely because
> the docs are, overall, more clear about the GPIO compatibility
> than about the EEPROM.
>   
Makes a certain amount of sense but given that the at24 driver is quite
specific about the use of generic chip names, whereas the pcf857x is
listing devices would it not make more sense to add it there with help
text explaining that eeprom is supported by the at24 driver?

Pesky dual purpose chips get in the way of nice clean naming conventions!
>   
>> As the Kconfig title for these is getting a bit long and the
>> datasheet for these starts with stating they are pcf957x
>> compatible so I haven't changed it. 
>>     
>
> Right; helptext can have a sentence.
>   
Indeed.

Actually that's looking to be the only bit of the patch that will be needed.

--
Jonathan