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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox