mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.


  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®