pca953x GPIO

pca953x GPIO

[Giampaolo Bellini]

Hi all...

  I'm new to I2c and I'm in trouble trying to get GPIO works on an
Advantech PCM-3362 motherboard.

manufacturer says that GPIO controller is an NXP PCA9555PW chip,
attached to the i2c BUS; the chip has the addresses 40 (read) and 41
(write) but, if I'm not wrong, in his linux libsusi library
manufacturer access GPIO via BIOS calls and not via linux i2c.

CPU is an intel Atom N450 with ICH8M chipset and it seems that SMBUS
controller is correctly recognized by the kernel as dmegs reports
something like:
i801_smbus 0000:00:1f.3: PCI INT C -> GSI 17 (level, low) -> IRQ 17

actually I've configured the latest 2.6.34 kernel with i2c and pca953x
drivers, but /sys/class/gpio reports only import / export entries,
with no GPIO chips at all...

I've read Documents/gpio.txt but still don't understand if I have to
do something more to enable GPIO: as I want to access it from kernel
space, I think I'll need to write my own driver (calling
gpio_request() etc) but still miss info about GPIO numbers... and I'm
not even sure GPIO is currently detected.

Ive try also registering a new GPIO device using generic gpiolib &
sysfs support (eg: echo GPIO-RD 0x40 >
/sys/bus/i2c/devices/i2c-0/new_device) but with no success.


   thanks a lot for any ideas

             Giampaolo Bellini

Re: pca953x GPIO

[Jean Delvare]

Hi Giampaolo,

On Wed, 23 Jun 2010 14:02:04 +0200, Giampaolo Bellini wrote:
> Hi all...
> 
>   I'm new to I2c and I'm in trouble trying to get GPIO works on an
> Advantech PCM-3362 motherboard.
> 
> manufacturer says that GPIO controller is an NXP PCA9555PW chip,
> attached to the i2c BUS; the chip has the addresses 40 (read) and 41
> (write) but, if I'm not wrong, in his linux libsusi library

This means they refer to left-aligned addresses. Linux uses
right-aligned addresses, so your device lives at 0x20 as far as Linux
is concerned.

> manufacturer access GPIO via BIOS calls and not via linux i2c.
> 
> CPU is an intel Atom N450 with ICH8M chipset and it seems that SMBUS
> controller is correctly recognized by the kernel as dmegs reports
> something like:
> i801_smbus 0000:00:1f.3: PCI INT C -> GSI 17 (level, low) -> IRQ 17
> 
> actually I've configured the latest 2.6.34 kernel with i2c and pca953x
> drivers, but /sys/class/gpio reports only import / export entries,
> with no GPIO chips at all...
> 
> I've read Documents/gpio.txt but still don't understand if I have to
> do something more to enable GPIO: as I want to access it from kernel
> space, I think I'll need to write my own driver (calling
> gpio_request() etc) but still miss info about GPIO numbers... and I'm
> not even sure GPIO is currently detected.

Check arch/arm/mach-ks8695/board-acs5k.c and
arch/arm/mach-pxa/cm-x300.c for examples.

> Ive try also registering a new GPIO device using generic gpiolib &
> sysfs support (eg: echo GPIO-RD 0x40 >
> /sys/bus/i2c/devices/i2c-0/new_device) but with no success.

Wrong name and wrong address, no surprise it didn't work. Try instead:

echo pca9555 0x20 > /sys/bus/i2c/devices/i2c-0/new_device

(Assuming i2c-0 is the bus on which the chip actually lives - you can
check with i2cdetect). That being said, I doubt that a GPIO chip can
really be instantiated from user-space, as it needs configuration
settings which you can't provide that way.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

Re: pca953x GPIO

[Giampaolo Bellini]

Hello Jean

  thanks you so much for your time!

> This means they refer to left-aligned addresses. Linux uses
> right-aligned addresses, so your device lives at 0x20 as far as Linux
> is concerned.

effectively, after hours and hours of testing, I found by myself that
the correct addressed where 0x20 and 0x21 but was not able to
understand why the manufacturer gives me what I think was a wrong
registers map !

> Check arch/arm/mach-ks8695/board-acs5k.c and
> arch/arm/mach-pxa/cm-x300.c for examples.

I'll check these source in the next days... so pca953x driver could
just export his services to other modules ? does it nothing alone
and/or paired with gpiolib ? or it's just a question of give the
pca953x some platforms data ?

> (Assuming i2c-0 is the bus on which the chip actually lives - you can
> check with i2cdetect). That being said, I doubt that a GPIO chip can
> really be instantiated from user-space, as it needs configuration
> settings which you can't provide that way.

you are right... i've try yesterday with the correct addresses but
with no success.

thanks again...

     Giampaolo

Re: pca953x GPIO

[Jean Delvare]

On Thu, 24 Jun 2010 19:49:00 +0200, Giampaolo Bellini wrote:
> Hello Jean
> 
>   thanks you so much for your time!
> 
> > This means they refer to left-aligned addresses. Linux uses
> > right-aligned addresses, so your device lives at 0x20 as far as Linux
> > is concerned.
> 
> effectively, after hours and hours of testing, I found by myself that
> the correct addressed where 0x20 and 0x21 but was not able to

Just 0x20, not "0x20 and 0x21". The "address byte" that goes on the
wire is made of 7 bits of address and 1 bit of direction (read or
write). 0x40 is (0x20 << 1) | 0, 0x41 is (0x20 << 1) | 1.

> understand why the manufacturer gives me what I think was a wrong
> registers map !

These are device addresses, nothing to do with a "register map".

> > Check arch/arm/mach-ks8695/board-acs5k.c and
> > arch/arm/mach-pxa/cm-x300.c for examples.
> 
> I'll check these source in the next days... so pca953x driver could
> just export his services to other modules ? does it nothing alone
> and/or paired with gpiolib ? or it's just a question of give the
> pca953x some platforms data ?

It is indeed just a question of instantiating the pca953x device with
some platform data.

> > (Assuming i2c-0 is the bus on which the chip actually lives - you can
> > check with i2cdetect). That being said, I doubt that a GPIO chip can
> > really be instantiated from user-space, as it needs configuration
> > settings which you can't provide that way.
> 
> you are right... i've try yesterday with the correct addresses but
> with no success.

-- 
Jean Delvare

Re: pca953x GPIO

[Joan Pau Beltran]

Hi everyone,

We are also working with an Advantech PCM3362 board in an underwater 
vehicle, and want to use the GPIO port to monitor the battery charge (a 
battery board is connected to the GPIO port and sets a pin to 1 when 
voltage goes below 20V).

We need to use Ubuntu, currently 10.04 with kernel 
linux-image-2.6-32-26-generic.

As Giampolo says, out of the box there aren't any chips under 
/sys/class/gpio (only import/export files).
After checking that i2c-gpio and pca953x are shipped with the kernel but 
no loaded by default, I tried to modprobe them and they load 
successfully, but the chip does not appear in /sys/class/gpio.
i2cdetect does not list any bus.

The battery board is not connected to the GPIO now. Actually nothing is 
connected to it. I suppose that the chip should be detected even if 
there is nothing attached to it. But just to be sure, do I need to 
connect it to some device to get the chip appear under /sys/class/gpio?

Giampolo (ore anyone on the list), did you success using the GPIO port 
on that board? In that case, could you point me what steps have you 
done? It's the first time I use a GPIO port and I read the Documentation 
and both examples pointed out by Jean but still can not figure out why 
the chip is not recognized under /sys/class/gpio or how to access it.

Thanks Jean for pointing out about the address alignment difference in 
Linux. For sure I won't even thought about it reading the Advantech manual.

Thanks in advance, and please excuse my English!

Re: pca953x GPIO

[Jean Delvare]

Hi Joan,

On Fri, 17 Dec 2010 18:21:57 +0100, Joan Pau Beltran wrote:
> We are also working with an Advantech PCM3362 board in an underwater 
> vehicle, and want to use the GPIO port to monitor the battery charge (a 
> battery board is connected to the GPIO port and sets a pin to 1 when 
> voltage goes below 20V).
> 
> We need to use Ubuntu, currently 10.04 with kernel 
> linux-image-2.6-32-26-generic.
> 
> As Giampolo says, out of the box there aren't any chips under 
> /sys/class/gpio (only import/export files).
> After checking that i2c-gpio and pca953x are shipped with the kernel but 
> no loaded by default, I tried to modprobe them and they load 
> successfully, but the chip does not appear in /sys/class/gpio.
> i2cdetect does not list any bus.

When you load the i2c-gpio driver, it looks for support devices. So
your platform initialization code must instantiate a platform device
with name "i2c-gpio" and proper platform data (GPIO pin descriptions).
There are several examples under arch/blackfin and arch/arm you can
look at.

If done properly, after loading i2c-dev, i2cdetect should see your I2C
bus. Until you manage to get there, there is no point in using driver
pca953x, it simply can't work.

> The battery board is not connected to the GPIO now. Actually nothing is 
> connected to it. I suppose that the chip should be detected even if 
> there is nothing attached to it. But just to be sure, do I need to 
> connect it to some device to get the chip appear under /sys/class/gpio?
> 
> Giampolo (ore anyone on the list), did you success using the GPIO port 
> on that board? In that case, could you point me what steps have you 
> done? It's the first time I use a GPIO port and I read the Documentation 
> and both examples pointed out by Jean but still can not figure out why 
> the chip is not recognized under /sys/class/gpio or how to access it.
> 
> Thanks Jean for pointing out about the address alignment difference in 
> Linux. For sure I won't even thought about it reading the Advantech manual.

-- 
Jean Delvare

Re: pca953x GPIO

[Joan Pau Beltran]

Thank you very much Giampolo
(and funny to see that my name is the same than yours, but in Catalan)

 From your notes:
> mknod /dev/i2c-0 c 89 0
> modprobe i2c-dev
> i2cdetect -l
>>>> i2c-0   smbus           SMBus I801 adapter at 0400              SMBus adapter
> i2cget 0 0x20

I see that you can access the chip. I will test it on monday or tuesday.
Do you know if we can access the N'th pin on the chip with 'i2cget 0 
0x20 N' (N in 0..7)?
And do you know if we can access these pins directly from a C program (I 
mean without using a system call) ?

Thanks again for your responses!

Re: pca953x GPIO

[Joan Pau Beltran]

Thank you very much Jean and Giampolo.

After reading again the kernel GPIO Documentation, I have some doubts 
that I would like to resolve and any word about them would be 
apreciated. Please excuse me if the following questions seem too obvious 
or are wrong formulated. I am very new to I2C and GPIO and can not get 
much more information from the results of my searches.

 From Jean's words and the following citation in the GPIO Documentation

> 523    Board Support
> 524    -------------
> 525    For external GPIO controllers -- such as I2C or SPI expanders, 
> ASICs, multi
> 526    function devices, FPGAs or CPLDs -- most often board-specific 
> code handles
> 527    registering controller devices and ensures that their drivers 
> know what GPIO
> 528    numbers to use with gpiochip_add().  Their numbers often start 
> right after
> 529    platform-specific GPIOs.
> 530
> 531    For example, board setup code could create structures 
> identifying the range
> 532    of GPIOs that chip will expose, and passes them to each GPIO 
> expander chip
> 533    using platform_data.  Then the chip driver's probe() routine 
> could pass that
> 534    data to gpiochip_add().


This platform-specific code is what Jean refers to, and must be compiled 
into the kernel.
If this is right, do we need to recompile the whole kernel with the new 
code for your board, or we can compile only the code for a particular 
board and load it as a module? And then, how can we access to the GPIO 
pins from a userspace program?

In several pages I have read three different modules are mentioned, 
namely pca953x, i2c-dev and i2c-gpio. Could anybody clarify what is the 
exact function of each of these modules, please?

Does the pca953x just use the previous platform code and the general 
GPIO support kernel facilities to expose the GPIO chip in the user space 
under /sys/class/gpio ?

Does the i2c-dev module give an alternative way to access to a generic 
i2c device via i2cget? If this is true, how can we access the GPIO pins 
from a program in that case?

What does the i2c-gpio module do?

Thanks everyone in advance.

Re: pca953x GPIO

[Joan Pau Beltran]

Hi everyone

Giampolo, thank you so much for your time.
I hope you and everyone in the list enjoy a happy and not too white 
Christmas.

My tries following Giampolo's steps first failed,
but thanks to his first mail on this subject and his last suggestions,
I get what I think are lectures from the gpio pins.

Here it goes the whole story:

After successfully loading the i2c-dev module via modprobe,
two new devices are automatically created (i2c-0 and i2c-1)
with major number 89 and minor numbers 0 and 1 respectively. This seems ok.
However any of them appears to i2cdetect as a SMBus
(in contrast with Giampolo's console output):

i2cdetect -l
i2c-0    i2c        intel drm CRTDDC_A           I2C adapter
i2c-1    i2c        intel drm LVDSDDC_C          I2C adapter

i2cdetect 0 (or i2cdetect 1) does not find any device at any address.
I get the same results in Ubuntu Lucid and Maverick on the same machine
(with kernels 2.6.32-27 and 2.6.35-22 respectively).

Also in contrast with Giampolo's kernel messages in the first post
(i801_smbus 0000:00:1f.3: PCI INT C -> GSI 17 (level, low) -> IRQ 17),
there aren't any smbus mentions in my dmesg.

Looking for smbus modules, in Maverick I found the module i2c-smbus,
but after loading successfully it has no effect. i2cdetect does not show 
any extra bus.
In Lucid, I did not found the i2c-smbus module, but thanks to Giampolo's 
dmesg line
I eventually caught the i2c-i801 module in the output of modprobe -l.

After loading it, i2cdectect shows an extra bus:
i2c-0    i2c       intel drm CRTDDC_A             I2C adapter
i2c-1    i2c       intel drm LVDSDDC_C            I2C adapter
i2c-2    smbus     SMBus I801 adapter at 0400     SMBus adapter

Now i2cdump give this output
(all lines except the first one stripped because they are empty):

i2cdump -y 2 0x20
No size specified (using byte-data access)
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: ff ff ff ff 00 00 ff ff XX XX XX XX XX XX XX XX    ........XXXXXXXX

I am surprised about these values. The port has 8 gpio pins available,
so it seems their addresses are the ones in 000-007
(or shoud I say they are represented in the chip's register 000-007?).
However, since there is nothing connected to the gpio pins,
I expected all their values to be equal 00. Is this normal?
 From where can these values can come from?

Giampolo, do you remember which distribution did you use?
Did it load some smbus driver automatically (maybe through udev)?
Or do you remember adding any extra module to /etc/modules.

It seems that I should add i2c-dev and i2c-i801 to my /etc/modules.
Can someone confirm that? Would it be better to make udev load them 
automatically?
How can this be done?

Sorry for the long mail, I wrote it expecting that it could be useful
for other people dealing with similar issues.

Thanks again.

Al 25/12/10 12:24, En/na Giampaolo Bellini ha escrit:
> Hello Joan Pau.... an happy christmas !
>
> if I don't remember wrong, 0x20 is the address of the port/function...
> while the first number is the address of the bus.
> the value returned from the command should be the hexadecimal-encoded
> status of the port (viewed as an input)
>
> in order to control the port you should use i2cput with a third number
> that is the hex value of the desired outputs.
> I'm writing using a window machine now... so I cannot check it right now.
>
> from within a C program you can just open the /dev/i2c-0 device and do
> ioctl on it... maybe that's the simplest way.
>
> Buon Natale,
>
>         Giampaolo
>
>
> 2010/12/24 Joan Pau Beltran<joanpau.beltran-i5CWTa81U/w@public.gmane.org>:
>> Thank you very much Giampolo
>> (and funny to see that my name is the same than yours, but in Catalan)
>>
>>  From your notes:
>>> mknod /dev/i2c-0 c 89 0
>>> modprobe i2c-dev
>>> i2cdetect -l
>>>>>> i2c-0   smbus           SMBus I801 adapter at 0400              SMBus
>>>>>> adapter
>>> i2cget 0 0x20
>> I see that you can access the chip. I will test it on monday or tuesday.
>> Do you know if we can access the N'th pin on the chip with 'i2cget 0 0x20 N'
>> (N in 0..7)?
>> And do you know if we can access these pins directly from a C program (I
>> mean without using a system call) ?
>>
>> Thanks again for your responses!
>>

Re: pca953x GPIO

[Jean Delvare]

On Tue, 28 Dec 2010 17:04:37 +0100, Joan Pau Beltran wrote:
> Now i2cdump give this output
> (all lines except the first one stripped because they are empty):
> 
> i2cdump -y 2 0x20
> No size specified (using byte-data access)
>       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
> 00: ff ff ff ff 00 00 ff ff XX XX XX XX XX XX XX XX    ........XXXXXXXX
> 
> I am surprised about these values. The port has 8 gpio pins available,
> so it seems their addresses are the ones in 000-007
> (or shoud I say they are represented in the chip's register 000-007?).

No, it doesn't work like that. You'll have to download the datasheet
for your GPIO chip from nxp.com, to find out the meaning of each
register. The details are normally hidden from you if you use the
pca953x driver, but as you decided to go the hard way...

> However, since there is nothing connected to the gpio pins,
> I expected all their values to be equal 00. Is this normal?
>  From where can these values can come from?

You really want to read the datasheet. With i2cdump, i2cget and i2cset,
you get raw access to the device registers, so don't expect anything to
be easy and straightforward.

> (...)
> It seems that I should add i2c-dev and i2c-i801 to my /etc/modules.
> Can someone confirm that? Would it be better to make udev load them 
> automatically?
> How can this be done?

i2c-i801 should get loaded automatically, as it is a PCI driver. If it
isn't on your system, make sure you didn't blacklist it. The following
command may help:

$ /sbin/modprobe -c | grep i2c_i801

i2c-dev is never loaded automatically, so you indeed have to add it
to /etc/modules (or whatever your distribution-specific mechanism is)
if you need it. OTOH you have to be root to run i2cdump or i2cget, so
you might as well load i2c-dev manually as root too.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

Re: pca953x GPIO

[Jean Delvare]

Hi Joan Pau,

On Fri, 24 Dec 2010 17:15:49 +0100, Joan Pau Beltran wrote:
> Thank you very much Jean and Giampolo.
> 
> After reading again the kernel GPIO Documentation, I have some doubts 
> that I would like to resolve and any word about them would be 
> apreciated. Please excuse me if the following questions seem too obvious 
> or are wrong formulated. I am very new to I2C and GPIO and can not get 
> much more information from the results of my searches.
> 
>  From Jean's words and the following citation in the GPIO Documentation
> 
> > 523    Board Support
> > 524    -------------
> > 525    For external GPIO controllers -- such as I2C or SPI expanders, ASICs, multi
> > 526    function devices, FPGAs or CPLDs -- most often board-specific code handles
> > 527    registering controller devices and ensures that their drivers know what GPIO
> > 528    numbers to use with gpiochip_add().  Their numbers often start right after
> > 529    platform-specific GPIOs.
> > 530
> > 531    For example, board setup code could create structures identifying the range
> > 532    of GPIOs that chip will expose, and passes them to each GPIO expander chip
> > 533    using platform_data.  Then the chip driver's probe() routine could pass that
> > 534    data to gpiochip_add().
> 
> 
> This platform-specific code is what Jean refers to, and must be compiled 
> into the kernel.
> If this is right, do we need to recompile the whole kernel with the new 
> code for your board, or we can compile only the code for a particular 
> board and load it as a module? And then, how can we access to the GPIO 
> pins from a userspace program?

Yes, you typically have to rebuild your kernel with specific platform
code for your new system, even though it would certainly be possible to
hack up an external kernel module instantiating the required I2C device.

In your specific case, it may be enough to add some custom code to the
i2c-i801. If you look at the end of function i801_probe, you'll see
such code already for a few systems. You can add your own system there.

I am not too familiar with the gpio subsystem, but my understanding is
that you can ask for your chip to expose its pins to user-space through
sysfs. It might even be the default.

> In several pages I have read three different modules are mentioned, 
> namely pca953x, i2c-dev and i2c-gpio. Could anybody clarify what is the 
> exact function of each of these modules, please?

i2c-gpio is used when you have an I2C bus hanging off 2 GPIO pins,
which are used to bit-bang the SDA and SCL lines of the bus. From your
previous system description, I don't think you need this, as your I2C
bus is handled by the i2c-i801 driver already.

pca953x is a device driver for I2C-based GPIO chips. If you have a
compatible I/O expander connected to your I2C bus, this is the driver
you want.

i2c-dev is a generic driver granting user-space access to I2C buses on
your system. It can be used to deal with I2C devices which don't have a
kernel driver yet, or for which you don't want to write or use a kernel
driver. But the most frequent use is for debugging, using i2c-tools
(i2cdump etc.)

> Does the pca953x just use the previous platform code and the general 
> GPIO support kernel facilities to expose the GPIO chip in the user space 
> under /sys/class/gpio ?

Yes, exactly.

> Does the i2c-dev module give an alternative way to access to a generic 
> i2c device via i2cget? If this is true, how can we access the GPIO pins 
> from a program in that case?

Yes, this is true, but as I said in my other reply already, i2cget
gives raw access to the registers, so you have a lot of work left to
make sense of the values. Basically, using i2c-dev to access a PCA953x
chip means you recode the pca953x driver in user-space. Honestly, I
don't get the point. Well, yes, of course, it saves you the step of
properly declaring the I2C device in the kernel, but the cost seems
very high.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

Re: pca953x GPIO

[Joan Pau Beltran]

Hello everyone!

Al 06/01/11 16:22, En/na Jean Delvare ha escrit:
> On Tue, 28 Dec 2010 17:04:37 +0100, Joan Pau Beltran wrote:
>> Now i2cdump give this output
>> (all lines except the first one stripped because they are empty):
>>
>> i2cdump -y 2 0x20
>> No size specified (using byte-data access)
>>        0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
>> 00: ff ff ff ff 00 00 ff ff XX XX XX XX XX XX XX XX    ........XXXXXXXX
>>
>> I am surprised about these values. The port has 8 gpio pins available,
>> so it seems their addresses are the ones in 000-007
>> (or shoud I say they are represented in the chip's register 000-007?).
> No, it doesn't work like that. You'll have to download the datasheet
> for your GPIO chip from nxp.com, to find out the meaning of each
> register. The details are normally hidden from you if you use the
> pca953x driver, but as you decided to go the hard way...
You are right. I noticed that after playing around with the chip and the 
demo application from Advantech (for windows only). Then I went straight 
to the chip's data sheet and found each register's function.

The chip has 2 input/output ports (port0 and port1), each one with 8 
GPIO pins
(so it seems that only the first one is available for the user with 
these board).
The eight registers are for (respectively) Input0 (0), Input1(1), 
Output0 (2), Output1 (3), Polarity Inversion0 (4), Polarity Inversion1 
(5), Direction0 (6) and Direction1 (7).
The byte in each register represent the state of the eight pins as a 
bitmask.
To read the state of a pin (no matter if it is an input or output pin) 
you should read the register 0 (0xff mean all pins high, 0x00 means all 
pins low, 0xf0 means the first four pins low and the other four pins 
high, etc).
The direction of each pin may be set the same way with the register 6 (1 
means input and 0 means output, so setting the register to 0xf0 means 
the first four pins are for output and the other for for input, etc).
The polarity inversion for each pin may be set the same way but with 
register 4.
To set the state of the output pins you should write to the register 2 
the bitmask representing the pins you want to bring up (if you want to 
raise pins 0 and 1 you should write 0x03, etc).

I think we will do the things this way (with i2c-dev and reading the 
chip's registers) because the code to read the state of the pins is 
simple and we do not need to recompile the kernel. The cost is that root 
privileges will be needed to manage the GPIO. But I agree that a more 
elegant way could be adding platform code for the kernel and use the 
sysfs interface, allowing non-root access to the GPIO.

>> (...)
>> It seems that I should add i2c-dev and i2c-i801 to my /etc/modules.
>> Can someone confirm that? Would it be better to make udev load them
>> automatically?
>> How can this be done?
> i2c-i801 should get loaded automatically, as it is a PCI driver. If it
> isn't on your system, make sure you didn't blacklist it. The following
> command may help:
>
> $ /sbin/modprobe -c | grep i2c_i801
This is the above command's output:

modprobe -c | grep i2c_i801

blacklist i2c_i801
alias pci:v00008086d00001C22sv*sd*bc*sc*i* i2c_i801
...

And more alias. So the module is effectively blacklisted. In  
/etc/modprobe.d/blacklist.conf we found

# causes failure to suspend on HP compaq nc6000 (Ubuntu: #10306)
blacklist i2c_i801

Commenting the line should allow automatic loading of the module.

Thank you very much everyone for this discussion, specially Giampolo and 
Jean.
Your help has been invaluable.

Re: pca953x GPIO

[Joan Pau Beltran]

Hi everyone,

This mail is to let everybody notice that since kernel version 3.1, the 
pca953x module handles properly the chip WITHOUT the need of platform 
specific data. This means that, from user space, you can manage the pins 
through the /sys/class/gpio interface (provided by kernel's gpiolib 
framework) without building a new kernel with the platform code. You 
just need to read / write to the correct files. E.g.

# Register the chip on the proper bus.
# A new directory should whose name ends with a chip number N:
#   /sys/class/gpio/gpiochip240
echo pca9555 0x20 > /sys/bus/i2c/devices/i2c-0/new_device

# Request the wanted pin number M on the chip number N (chip number + 
pin number).
# A new directory should appear:
#   /sys/class/gpio/gpioN+M
echo 240 > /sys/class/gpio/export
echo 241 > /sys/class/gpio/export

# Get the pin state:
cat /sys/class/gpio/gpio240/value

# Set pin direction:
echo 'out' > /sys/class/gpio/gpio241/direction

# Set pin state:
echo '1' > /sys/class/gpio/gpio241/value

Regards,

-- 
Joan Pau Beltran
Grup de Sistemes, Robòtica i Visió - DMI
Universitat de les Illes Balears
Ctra. Valldemossa, km 7.5 07122 Palma
Campus Universitari, edifici Anselm Turmeda
Telf (+34) 971 17 28 13
Fax (+34) 971 17 30 03