linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: stigge@antcom.de (Roland Stigge)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RESEND 1/5 v6] gpio: Add a block GPIO API to gpiolib
Date: Fri, 02 Nov 2012 10:22:22 +0100	[thread overview]
Message-ID: <509390CE.90402@antcom.de> (raw)
In-Reply-To: <CACxGe6vEr5fd0_ZuzV=nOXVfwA7_FB5L6KJsEwMEHmVj0rDA=g@mail.gmail.com>

On 10/31/2012 07:59 PM, Grant Likely wrote:
>> Pin direction currently needs to be set up separately, analogous to
>> requesting gpios. Need to document this better, right. The assumption is
>> that I/O needs to be efficient primarily, before bloating the API with
>> direction functions. Or should I add functions for this?
> 
> Since this is a userspace facing ABI, once it is merged it cannot be
> changed in an incompatible way. I cannot merge it until there is at
> least a plan for how to handle all of the reasonable use cases. That
> means it must support set/clear or mask operations. Also, if it sticks
> with the design of grouping pins from multiple controllers, then it
> needs to handle explicitly constraining what order operations are
> performed in at the time of the operation. At the time of setup
> doesn't work since constraints between pins may not always be in the
> same order.
> 
> I really think you should consider implementing a command stream type
> of interface.

Yes, understand. What do you consider a good example of a command stream
type interface? Link or hint appreciated!

There was already mentioned the idea of a device node which can be
interfaced to via ioctl() for the various operations. Can it be a
"struct miscdevice" or do you require sth. more sophisticated?

Thanks in advance,

Roland

  parent reply	other threads:[~2012-11-02  9:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-28 20:46 [PATCH RESEND 0/5 v6] gpio: Add block GPIO Roland Stigge
2012-10-28 20:46 ` [PATCH RESEND 1/5 v6] gpio: Add a block GPIO API to gpiolib Roland Stigge
2012-10-31 14:06   ` Linus Walleij
2012-10-31 17:47     ` Roland Stigge
2012-10-31 15:00   ` Grant Likely
2012-10-31 17:19     ` Roland Stigge
2012-10-31 18:59       ` Grant Likely
2012-11-01 14:44         ` Jean-Christophe PLAGNIOL-VILLARD
2012-11-02  9:22         ` Roland Stigge [this message]
2012-10-31 19:30     ` Mark Brown
2012-11-01 15:14       ` Grant Likely
2012-10-28 20:46 ` [PATCH RESEND 2/5 v6] gpio: Add sysfs support to block GPIO API Roland Stigge
2012-10-28 20:46 ` [PATCH RESEND 3/5 v6] gpiolib: Fix default attributes for class Roland Stigge
2012-10-31 15:04   ` Grant Likely
2012-10-28 20:46 ` [PATCH RESEND 4/5 v6] gpio: Add device tree support to block GPIO API Roland Stigge
2012-10-31 15:05   ` Grant Likely
2012-10-28 20:46 ` [PATCH RESEND 5/5 v6] gpio: Add block gpio to several gpio drivers Roland Stigge

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=509390CE.90402@antcom.de \
    --to=stigge@antcom.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).