From: Grant Likely <grant.likely@secretlab.ca>
To: Jamie Iles <jamie@jamieiles.com>
Cc: Anton Vorontsov <cbouatmailru@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
Russell King <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>, Nicolas Pitre <nico@fluxnic.net>
Subject: Re: [PATCH] gpio: support for Synopsys DesignWare APB GPIO
Date: Mon, 4 Apr 2011 20:48:38 -0600 [thread overview]
Message-ID: <20110405024838.GA29522@ponder.secretlab.ca> (raw)
In-Reply-To: <20110403152244.GC5670@pulham.picochip.com>
On Sun, Apr 03, 2011 at 04:22:44PM +0100, Jamie Iles wrote:
> Hi Grant,
>
> On Sun, Apr 03, 2011 at 08:47:25AM -0600, Grant Likely wrote:
> > On Sun, Apr 3, 2011 at 8:07 AM, Jamie Iles <jamie@jamieiles.com> wrote:
> > > My first idea would be to have something like:
> > >
> > > struct mmio_gpio_bank {
> > > unsigned int ngpio;
> > > unsigned long set_offs;
> > > unsigned long clr_offs;
> > > unsigned long dout_offs;
> > > unsigned long din_offs;
> > > unsigned long dir_offs;
> > > };
> > >
> > > struct mmio_gpio_pdata {
> > > size_t bus_width_bits;
> > > int gpio_base;
> > > unsigned int nr_banks;
> > > struct mmio_gpio_bank banks[];
> > > };
> >
> > As discussed earlier in the thread, you probably don't need to support
> > multiple banks with this driver. Instead, create a separate device
> > instance for each bank.
>
> The reason I proposed this was for controllers where the registers
> aren't grouped together for each bank. For example, the Synopsys block
> has:
>
> 0x00-0x08 bank A control registers
> 0x0c-0x14 bank B control registers
> ...
> 0x50 bank A input register
> 0x54 bank B input register.
>
> So when you mentioned before using a single register resource with
> offsets I understood it to be something like what I've proposed
> otherwise multiple banks would have overlapping resources (or the
> resource would just be used to indicate the start address rather than
> start + end).
That may be a problem for request_mem_region() which would indeed
prevent the driver from specifying the full register range with
offsets inside it. I suspect that the platform_bus_type will inhibit
two platform_devices with overlapping regions from getting registered.
Fair enough, that is a pretty strong argument for Anton's model. I
don't think it would be a good idea to try and work around it by
making the resource only include the start address.
It does mean some gymnastics for a device tree binding to figure out
which registers are present, but the appropriate behaviour could be
selected by a set of compatible values for each kind of register
interface.
>
> Also, it's not clear here but this would create one gpio_chip per bank.
And that's bad why? :-)
g.
next prev parent reply other threads:[~2011-04-05 2:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-01 13:47 Jamie Iles
2011-04-01 15:17 ` Randy Dunlap
2011-04-02 22:10 ` Thomas Gleixner
2011-04-03 2:59 ` Jamie Iles
2011-04-03 4:45 ` Grant Likely
2011-04-03 9:30 ` Thomas Gleixner
2011-04-03 12:03 ` Anton Vorontsov
2011-04-03 14:07 ` Jamie Iles
2011-04-03 14:47 ` Grant Likely
2011-04-03 15:22 ` Jamie Iles
2011-04-04 10:40 ` Anton Vorontsov
2011-04-05 2:48 ` Grant Likely [this message]
2011-04-05 8:18 ` Jamie Iles
2011-04-05 11:47 ` Anton Vorontsov
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=20110405024838.GA29522@ponder.secretlab.ca \
--to=grant.likely@secretlab.ca \
--cc=arnd@arndb.de \
--cc=cbouatmailru@gmail.com \
--cc=jamie@jamieiles.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nico@fluxnic.net \
--cc=tglx@linutronix.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
all inboxes | Powered by JetHome®