[i2c] [PATCH] basic gpio_chip support for 16-bit PCA9539 GPIO expander

[eric miao]

On Dec 4, 2007 3:52 AM, David Brownell <david-b at pacbell.net> wrote:
> On Monday 03 December 2007, eric miao wrote:
> > > And none of the IRQ logic should be included in modular builds;
> > > see below.
>
> In fact, since Jean suggests this go through me, I'll ask that you
> split it in two parts:  the GPIO bits, then separately adding that
> IRQ handling infrastructure.  In the first part, you can just emit
> some message when (i2c_client.irq > 0), as a reminder that IRQs are
> ignored.
>

OK.

> That would split the relatively non-controversial part -- pure GPIO
> support -- into something that's easy to merge upstream.  Did you
> verify that nobody in mainline needs legacy driver support for
> these chips, by the way?
>

#> grep -iR "pca9539" *

gave me the following potential users of pca9539:

arch/mips/configs/bigsur_defconfig:CONFIG_SENSORS_PCA9539=y
arch/mips/configs/mtx1_defconfig:CONFIG_SENSORS_PCA9539=m
...
arch/arm/configs/picotux200_defconfig:CONFIG_SENSORS_PCA9539=m
...

and I doubt if these defconfigs are sane about their I2C configurations
(if you don't mind take a look into these files :-), and also with Ben's
acknowledgment, I don't think this would be a problem. If you don't
feel good about this, I can try adding those sysfs stuffs back, though
the final code might be a bit uglier.

> Then the funkier bits (IRQ handling) can be evaluated separately.
> I don't know that anyone has yet tried to use irq_chip in that
> way before:  where chitchat with the chip can't be done in IRQ
> context.  That alone pretty much ensures that discussion will be
> needed ... and it'll be easier to have that discussion based on
> patches that only address that new style of IRQ handling.  (FWIW
> the only I2C driver I know of in mainline that handles any kind
> of pluggable IRQ handler is the menelaus driver in that same
> directory.  It doesn't use irq_chip.)
>

Yes, because it's not an IRQ chip, the menelaus driver tries
only to access the I2C bus within interrupt context.

>
> This driver seems like it should handle pca9535 chips too;
> the key difference seems to be that the '39 has a reset input
> instead of the extra address pin on the '35.
>
> Plus several other chips in this family look to be similar
> enough that this driver should be able to handle them without
> much work at all.  The pc9538 is an 8 bit expander, so it maps
> GPIOs to registers slightly differently.  Likewise the pca9537
> is a 4-bit expander, just like the '38 except that the upper
> four bits of its registers are unused.
>

I don't have those chips to test, so I'd prefer someone modifying
this later.

> - Dave
>
>

-- 
Cheers
- eric