From: Peter Tyser <ptyser@xes-inc.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] gpio: add driver for PCA9539 16-bit I2C gpio expander
Date: Mon, 06 Dec 2010 19:34:05 -0600 [thread overview]
Message-ID: <1291685645.20072.736.camel@petert> (raw)
In-Reply-To: <AANLkTinRTXze5v7D25v1XqKgUfwNnOc_7JA=pyya1Wis@mail.gmail.com>
<snip>
> > You could do the same thing to the U-Boot pca953x driver.
> > Eg at the top you could add:
> > #ifdef CONFIG_PCA953X_16BIT
> > #define NGPIO = 16
> > #else
> > #define NGPIO = 8
> > #endif
>
> I have a small problem with this due to the fact that we have some
> designs here that use a pca9534 and a pca9539. Having a compile-time
> conditional like this means you can only support one or the other.
> Linux can handle this because it's actually got a structure that
> contains the 8 vs 16 whereas u-boot only has the address an no other
> information. Any suggestions on handling this would be welcome.
Some ideas:
- Do a series of byte reads and determine the number of GPIOs based on
mirroring of registers, or reads failing if they are past the "end" of
the device. eg reading register 4 on a 8-bit device might fail, or wrap
around and return the same data as register 0.
- Make CONFIG_PCA953X_16BIT an array that lists which I2C address
support 16 bits, then use it to determine which devices are 8 vs 16 bits
dynamically.
- Convert the driver to be more intelligent. eg add an interface like
pca953x_add_dev(u8 addr, u8 bits) which each board calls to add a device
to a list of devices maintained by the pca953x driver. Eg in my board
code I'd do:
pca953x_add_dev(0x18, 8);
pca953x_add_dev(0x1c, 8);
pca953x_add_dev(0x1e, 8);
pca953x_add_dev(0x1f, 8);
Best,
Peter
next prev parent reply other threads:[~2010-12-07 1:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-06 21:48 [U-Boot] [PATCH] gpio: add driver for PCA9539 16-bit I2C gpio expander Chris Packham
2010-12-07 0:13 ` Peter Tyser
2010-12-07 1:12 ` Chris Packham
2010-12-07 1:34 ` Peter Tyser [this message]
2010-12-07 1:50 ` Chris Packham
2010-12-07 4:31 ` Peter Tyser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1291685645.20072.736.camel@petert \
--to=ptyser@xes-inc.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.