Thread (20 messages) 20 messages, 4 authors, 2015-10-02

[PATCH 2/2] Documentation: gpio: Update description for X-Gene standby GPIO controller DTS binding

From: arnd@arndb.de (Arnd Bergmann)
Date: 2015-09-14 09:11:05
Also in: linux-devicetree, linux-gpio

On Saturday 12 September 2015 12:55:55 Y Vo wrote:
On Fri, Sep 11, 2015 at 11:45 PM, Arnd Bergmann [off-list ref] wrote:
quoted
On Friday 11 September 2015 22:06:58 Y Vo wrote:
quoted
On Fri, Sep 11, 2015 at 9:47 PM, Arnd Bergmann [off-list ref] wrote:
quoted
On Friday 11 September 2015 21:23:31 Y Vo wrote:
quoted
Is that possible if we change to this approach:
- Keep all GPIO as GPIO mode by default.
- If anyone want to use them as interrupt, they must add the interrupt
node to DT specific-board below:

Example to configure GPIO_DS11, 12, 13 as external irq:

&sbgpio {
        interrupts = <0x0 0x2b 0x1>,         /* GPIO_DS11 */
                        <0x0 0x2c 0x1>,         /* GPIO_DS12 */
                        <0x0 0x2d 0x1>;         /* GPIO_DS13 */
That is exactly the same as you have in your patch. You should
always list all interrupts that the gpio controller is wired
to, whether they are used or not.

Ideally, the driver just decides at runtime how to wire that
mux, based on how the gpio is configured by the client driver.
If the client asks for an interrupt (with gpio_to_irq) and is
it is configured as an input, then you connect it to the GIC,
otherwise you leave it to be handled by the gpio chip itself.
Any reason you can't do that?
As I just explained, the GPIO Standby doesn't support the interrupt.
Both interrupts are came from GIC, so if the client asks for an
interrupt, it will go to the GIC driver (not GPIO Standby driver), so
that's my trouble. We can not implement the code to configured the
GPIO standby at GIC driver.
So you are saying we merged a binding that is incapable of describing
the hardware? If that is the case, we may have to go back to
the drawing board and come up with a working binding.

One part that I don't understand yet is how the driver handles
irqs to start with, as it does not register a nested irq domain
or irqchip, so I'm guessing that client drivers cannot actually
use the IRQ functionality. Is that right?
For our case the irq_domain is in irq-gic driver, the GPIO driver only
is responsible to wire 2 the external irq of GIC to GPIO pin.

Example for configure GPIO_DS13 as interrupt and use as button with
the current gpio driver:
        gpio-keys {
                compatible = "gpio-keys";
                button at 1 {
                        label = "POWER";
                        linux,code = <116>;
                        linux,input-type = <0x1>;
                        interrupts = <0x0 0x2d 0x1>;
                };
        };
Wait, this looks wrong: the gpio driver doesn't actually see
the connection here and won't be able to configure the interrupt
correctly. The interrupt is already owned by the gpio driver, so
you cannot use it in the button node.
quoted
It also seems to me that the binding cannot distinguish between a
line configured as an input and one that is configured as an
interrupt, which are for other gpio chips the same thing, but
not on this one.  Could this be rectified by using another bit
of the second gpio cell? The low bit is used for active-high/active-low,
so you could use the second bit for irq/input.
Do you mean #gpio-cells property and using the high bit of the second
bit for irq/input  ?
Yes, that would be an option.

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help