From: wg@grandegger•com (Wolfgang Grandegger)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 0/6 v8] gpio: Add block GPIO
Date: Wed, 05 Dec 2012 19:44:55 +0100 [thread overview]
Message-ID: <50BF9627.4050102@grandegger.com> (raw)
In-Reply-To: <50BE5F8A.2000903@antcom.de>
Hi Roland,
On 12/04/2012 09:39 PM, Roland Stigge wrote:
> Hi Wolfgang,
>
> On 03/12/12 10:17, Wolfgang Grandegger wrote:
>> I re-tried v8 on my AT91-SAM9G45 board and it works fine if
>> CONFIG_GPIO_SYSFS is enable. Unfortunately, the access via misc device
>> fails if CONFIG_GPIO_SYSFS is not set. That's due to gpio_block_export()
>> returning -ENOSYS in gpio_block_register().
>>
>> Anyway, I really like that new GPIO block interface making life for
>> applications fiddling with GPIOs much easier and faster. Just the poll
>> support is missing.
>
> Thanks for your feedback!
>
> I'm posting an update (v9) which includes poll() support in the dev
> interface.
I just gave it a try and it was working after replacing
IRQF_TRIGGER_FALLING with 0 in the request_irq in the device open:
# ./gpio_block_test
mask=0x7e
mask=0x7f
mask=0x7d
mask=0x7f
mask=0x77
mask=0x7f
Otherwise it get:
# ./gpio_block_test
genirq: Setting trigger mode 2 for irq 86 failed (gpio_irq_type+0x0/0x18)
can't open device /dev/gpiobuttons (Invalid argument)
Also opening with O_NONBLOCK works as expected.
> Some issues regarding IRQ driven poll() remain:
>
> * What would be the correct locking mechanism for the got_int flag (set
> in the isr and reset on read()'s return), if necessary at all?
If you sync against the interrupt context, I think spin_lock_irqsave and
spin_unlock_irqrestore should be used.
> * There is probably an explicit interrupt configuration necessary (via
> struct gpio_block, and devicetree, respectively) since there are
> constellations where gpio_to_irq() isn't working. E.g., in contrast to
> controllers which are aware of their IRQs and providing to_irq(), there
> is typically independent wiring from GPIO expander chips' interrupt line
> to individual IRQ inputs on SoCs/CPUs. Or should all this be solved via
> devicetree and drivers (which should support IRQ config where possible)?
Yes, I think it's up to the device tree or platform code to properly setup
the interrupt... like for defining the GPIO block.
> * For the same reason, the IRQ flags are currently IRQF_TRIGGER_FALLING,
> which isn't flexible. Instead, either preset by board setup/firmware, or
> via interrupts config in devicetree (optional property of a GPIO block?)
Yes, and it did fail on my setup.
> * Some GPIOs' IRQs are not suitable for GPI input change detection. E.g.
> on LPC32xx, I can configure the IRQ which is controlled directly by the
> GPI's values as FALLING, RISING, HIGH /exclusive/ or LOW. I.e., this way
> it's not possible to detect both 0->1 and 1->0 changes without
> reconfiguring the GPIO controller inbetween. Other controllers provide a
> dedicated interrupt on all values changes.
Hm.
> * Would IRQF_SHARED be appropriate to enable opening IRQ enabled GPIO
> blocks multiple times?
Sounds reasonable for me. Some more comments in the patch mails...
Wolfgang.
next prev parent reply other threads:[~2012-12-05 18:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 18:03 [PATCH 0/6 v8] gpio: Add block GPIO Roland Stigge
2012-11-30 18:03 ` [PATCH 1/6 v8] gpio: Add a block GPIO API to gpiolib Roland Stigge
2012-11-30 18:03 ` [PATCH 2/6 v8] gpio: Add sysfs support to block GPIO API Roland Stigge
2012-11-30 18:03 ` [PATCH 3/6 v8] gpio: Add userland device interface to block GPIO Roland Stigge
2012-11-30 18:03 ` [PATCH 4/6 v8] gpiolib: Fix default attributes for class Roland Stigge
2012-11-30 18:03 ` [PATCH 5/6 v8] gpio: Add device tree support to block GPIO API Roland Stigge
2012-11-30 18:03 ` [PATCH 6/6 v8] gpio: Add block gpio to several gpio drivers Roland Stigge
2012-12-03 9:17 ` [PATCH 0/6 v8] gpio: Add block GPIO Wolfgang Grandegger
2012-12-04 20:39 ` Roland Stigge
2012-12-05 18:44 ` Wolfgang Grandegger [this message]
2012-12-05 22:10 ` 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=50BF9627.4050102@grandegger.com \
--to=wg@grandegger$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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