On Jul 30 2010, Wookey wrote:
>+++ Marek Vasut [2010-07-30 06:44 +0200]:
>> Dne Čt 29. července 2010 12:00:41 Wookey napsal(a):
>> > +++ Marek Vasut [2010-07-29 05:16 +0200]:
>> > > Add supported for PCF8574A GPIO expander and LEDs attached to it.
>> >
>> > This IO board is an add-on used in some ballon configurations, not
>> > part of the core board. There needs to be some way of selecting this
>> > support when the loon is used in this configuration. We have the
>> > balloon_has() macro which is used for dealing with the different
>> > builds of the board itself. Perhaps it should be extended to deal with
>> > add-on board functionality too?
>> >
>> > More obvious is using the CONFIG system to just enable this if
>> > CUED_IO_BOARD is configured.
>>
>> You can just disable the PCF driver if you want to save space. In case
>> you won't have the CUED board connected, the driver will just fail to
>> probe so it's ok I believe.
>>
>> The macro could be extended, but do we want such a weird stuff in
>> kernel?
>
> That was how this list suggested we deal with the unprobe-able build
> variation, I beleive.
>
>> (especially if the driver can simply fail to probe).
I'd strongly recommend not adding anything at all in the kernel
to specifically support the CUED IO Board. The LEDs attached to
the PCF8574 on the board can be driven from user space quite easily
using programs such as as i2cset from the i2ctools package.
We've been using these boards at CUED for a number of years now
without any kernel support beyond i2c-pxa.ko and i2c-dev.ko.
If support is added for these LEDs in the kernel, it would be nice
if we could still write their PCF8574 device using the i2c-dev ioctls.
It would be inconvenient (for us) if the only way to set these LEDs
was by writing a 1 or 0 to /sys/devices/system/leds-gpio/balloon3:gpio:ledN
(or similar).
Best wishes,
Paul.
Paul Fidler
--
Cambridge University Engineering Department | Tel: +44 1223 332816
Trumpington Street, Cambridge, CB2 1PZ, UK | Fax: +44 1223 332662
(text/plain)