Re: [PATCH 07/11] x86, olpc-xo1-sci: Add GPE handler and ebook switch functionality

From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Daniel Drake <dsd@laptop.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, dilinger@queued.net
Subject: Re: [PATCH 07/11] x86, olpc-xo1-sci: Add GPE handler and ebook switch functionality
Date: Tue, 31 May 2011 13:28:46 +0200	[thread overview]
Message-ID: <4DE4D0EE.20907@linutronix.de> (raw)
In-Reply-To: <BANLkTimpFYMpQFY9J7pa0NygGoQ8dLdArA@mail.gmail.com>

Daniel Drake wrote:
> I looked into irq_chip alongside the CS5535 docs. Initially this
> looked like a good suggestion - any CS5535 GPIO can be mapped to one
> of 8 PIC-level interrupts, which seems like a good match for irq_chip.
> 
> However, this isn't what we're doing here.
> 
> CS5535 GPIOs can either be mapped to interrupts, *or* to a Power
> Management Event (PME). A PME is a CS5535-specific concept; its an
> event that will bring the system out of suspend if it is sleeping. In
> this case, we are mapping a GPIO to a PME. I'm not aware of any
> appropriate Linux abstraction for this. Thats all done in
> cs5535_gpio_setup_event().

Is this something like pin multiplexing? So it is either a GPIO pin with 
interrupt ability _or_ that PME thingy.
If so, would it make sense to hide it behind enable_irq_wake()? That call
could fail if you have already gpio_request() users for instance.

> The CS5535 also has a highly programmable PIC, with loads of possible
> input and mapping options. The call to cs5535_gpio_set_irq() then
> programs the PIC to map PME input to an IRQ line. This function is
> both misnamed and misplaced; it is unrelated to GPIOs and is simply
> one of the many generic knobs on the PIC. If there was one, this
> function should belong in a cs5535-pic driver, named something
> according to "IRQ Mapper Unrestricted Z Select High".

And once that is done, you can not use as a GPIO anymore, right?

> Thanks,
> Daniel

Sebastian