GPIO sysfs : set a wake source

GPIO sysfs : set a wake source

[Robert Jarzmik]

Hi Linus,

I was thinking on how to remove all "gpio_request()" from my board code
(arch/arm/mach-pxa/mioa701.c).

I have a small difficulty with the functionality provided by gpiolib in
userspace. This is what I need :
 - define a gpio as an input
 - define this gpio to be an interrupt source
 - define this interrupt to be a wake-up source

In kernel, I had : gpio_request(), request_irq(), and gpio_set_wake() (in
mioa701, this ends up in gsm_on_irq()).

In userspace I have :
 - echo 113 > /sys/class/gpio/export
 - echo in > /sys/class/gpio/gpio113/direction
 - echo both > /sys/class/gpio/gpio113/edge

And here, I don't know how to trigger a call to gpio_set_wake(113, 1). Do you
provide that API somewhere in sysfs that I didn't find ? Because that's what I
need to obliterate gpio calls from my board code.

Cheers.

-- 
Robert

GPIO sysfs : set a wake source

[Linus Walleij]

On Thu, May 9, 2013 at 2:59 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:

> I was thinking on how to remove all "gpio_request()" from my board code
> (arch/arm/mach-pxa/mioa701.c).
>
> I have a small difficulty with the functionality provided by gpiolib in
> userspace. This is what I need :
>  - define a gpio as an input
>  - define this gpio to be an interrupt source
>  - define this interrupt to be a wake-up source

This sounds like trying to remove board code by moving it to userspace
and basically starting to implement stuff that belongs in the kernel
in userspace just because someone says we should get rid of board
files :-)

Don't go down this path, let the kernel handle this kind of stuff.

Instead figure out how to make the subsystems we have and the
device trees express what you want to do.

In another thread I suggested that we add a GPIO "hogging"
mechanism to gpiolib, so that the gpio subsystem can by itself
"hog" (get) some GPIOs and set them up in certain modes.
This closely matches what the pin control subsystem will do
with some such things.

What do you think about this idea?

Yours,
Linus Walleij

GPIO sysfs : set a wake source

[Stephen Warren]

On 05/14/2013 03:29 AM, Linus Walleij wrote:
> On Thu, May 9, 2013 at 2:59 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> 
>> I was thinking on how to remove all "gpio_request()" from my board code
>> (arch/arm/mach-pxa/mioa701.c).
>>
>> I have a small difficulty with the functionality provided by gpiolib in
>> userspace. This is what I need :
>>  - define a gpio as an input
>>  - define this gpio to be an interrupt source
>>  - define this interrupt to be a wake-up source
> 
> This sounds like trying to remove board code by moving it to userspace
> and basically starting to implement stuff that belongs in the kernel
> in userspace just because someone says we should get rid of board
> files :-)
> 
> Don't go down this path, let the kernel handle this kind of stuff.
> 
> Instead figure out how to make the subsystems we have and the
> device trees express what you want to do.
> 
> In another thread I suggested that we add a GPIO "hogging"
> mechanism to gpiolib, so that the gpio subsystem can by itself
> "hog" (get) some GPIOs and set them up in certain modes.
> This closely matches what the pin control subsystem will do
> with some such things.
> 
> What do you think about this idea?

There's some merit to discussing the use of "GPIO hogging" for the
purpose of solving interactions between the IRQ and GPIO subsystems

However, the discussion above sounds like simply a list of GPIOs to
initialize at boot for the sole purpose of GPIO initialization. I
thought that had been discussed before and nak'd?

GPIO sysfs : set a wake source

[Robert Jarzmik]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 05/14/2013 03:29 AM, Linus Walleij wrote:
>> On Thu, May 9, 2013 at 2:59 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> 
>>> I was thinking on how to remove all "gpio_request()" from my board code
>>> (arch/arm/mach-pxa/mioa701.c).
>>>
>>> I have a small difficulty with the functionality provided by gpiolib in
>>> userspace. This is what I need :
>>>  - define a gpio as an input
>>>  - define this gpio to be an interrupt source
>>>  - define this interrupt to be a wake-up source
>> 
>> This sounds like trying to remove board code by moving it to userspace
>> and basically starting to implement stuff that belongs in the kernel
>> in userspace just because someone says we should get rid of board
>> files :-)
No, really, even it's true that it comes from someone asking me, now I have
though it a bit more through.

>> Don't go down this path, let the kernel handle this kind of stuff.
Oh really, where ?

Let me show you why it can't be a module.
In my case, I have a 2G modem connected to the soc :
 - the modem and 1 SoC UART are connected (TX, RX, CTS, ...)
 - the modem and SoC are connected through several gpios
   - one or two control to power up and reset the modem
   - one connected to the modem "ring" signal (the one I want a wakeup for).

So I have no module to handle my modem :
 - UART is handled by pxa-uart
 - control/reset by gpiolib
 - ring ... by nobody

So my point is that this ring *should* be handled by gpiolib, just as any casual
input gpio. Moreover, the "wake-up" ability should be activable/deactivable on
wish by userspace.

>> Instead figure out how to make the subsystems we have and the
>> device trees express what you want to do.
As I said above, I don't think it's the way to go. I have *no* subsystem to
address.
Devicetree can't help in the toggle to "activate" or "deactivate" the wakeup
upon this GPIO, can it ?

>> 
>> In another thread I suggested that we add a GPIO "hogging"
>> mechanism to gpiolib, so that the gpio subsystem can by itself
>> "hog" (get) some GPIOs and set them up in certain modes.
>> This closely matches what the pin control subsystem will do
>> with some such things.
>> 
>> What do you think about this idea?
I don't yet know. Let me think this more over. I'd like some literature if you
can provide (especially on LAKML).

> There's some merit to discussing the use of "GPIO hogging" for the
> purpose of solving interactions between the IRQ and GPIO subsystems
>
> However, the discussion above sounds like simply a list of GPIOs to
> initialize at boot for the sole purpose of GPIO initialization. I
> thought that had been discussed before and nak'd?
Now I have described a bit more the problem, I think this sentence would need to
be amended :)

Cheers.

-- 
Robert

GPIO sysfs : set a wake source

[Stephen Warren]

On 05/16/2013 01:39 PM, Robert Jarzmik wrote:
> Stephen Warren <swarren@wwwdotorg.org> writes:
> 
>> On 05/14/2013 03:29 AM, Linus Walleij wrote:
>>> On Thu, May 9, 2013 at 2:59 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>>>
>>>> I was thinking on how to remove all "gpio_request()" from my board code
>>>> (arch/arm/mach-pxa/mioa701.c).
>>>>
>>>> I have a small difficulty with the functionality provided by gpiolib in
>>>> userspace. This is what I need :
>>>>  - define a gpio as an input
>>>>  - define this gpio to be an interrupt source
>>>>  - define this interrupt to be a wake-up source
>>>
>>> This sounds like trying to remove board code by moving it to userspace
>>> and basically starting to implement stuff that belongs in the kernel
>>> in userspace just because someone says we should get rid of board
>>> files :-)
> No, really, even it's true that it comes from someone asking me, now I have
> though it a bit more through.
> 
>>> Don't go down this path, let the kernel handle this kind of stuff.
> Oh really, where ?
> 
> Let me show you why it can't be a module.
> In my case, I have a 2G modem connected to the soc :
>  - the modem and 1 SoC UART are connected (TX, RX, CTS, ...)
>  - the modem and SoC are connected through several gpios
>    - one or two control to power up and reset the modem
>    - one connected to the modem "ring" signal (the one I want a wakeup for).
> 
> So I have no module to handle my modem :
>  - UART is handled by pxa-uart
>  - control/reset by gpiolib
>  - ring ... by nobody
> 
> So my point is that this ring *should* be handled by gpiolib, just as any casual
> input gpio. Moreover, the "wake-up" ability should be activable/deactivable on
> wish by userspace.
> 
>>> Instead figure out how to make the subsystems we have and the
>>> device trees express what you want to do.
>
> As I said above, I don't think it's the way to go. I have *no* subsystem to
> address.
> Devicetree can't help in the toggle to "activate" or "deactivate" the wakeup
> upon this GPIO, can it ?

This sounds very similar to WiFi rfkill, although it's a MODEM not WiFi.

GPIO sysfs : set a wake source

[Robert Jarzmik]

Stephen Warren <swarren@wwwdotorg.org> writes:

>>>> Instead figure out how to make the subsystems we have and the
>>>> device trees express what you want to do.
>>
>> As I said above, I don't think it's the way to go. I have *no* subsystem to
>> address.
>> Devicetree can't help in the toggle to "activate" or "deactivate" the wakeup
>> upon this GPIO, can it ?
>
> This sounds very similar to WiFi rfkill, although it's a MODEM not WiFi.
Mmmm yes, similar. But with one big difference : RFKill is control of wireless
chip "up state", while the toggle I'm speaking of will purely say if the "input
GPIO" will trigger a wake-up from S3 or not.

If RFKill interface had a toggle to say "hardware rfkill button toggle can
wake-up the kernel out of S3" then it would be very similar.

Cheers.

-- 
Robert

GPIO sysfs : set a wake source

[Linus Walleij]

On Thu, May 16, 2013 at 9:39 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:

>>> Don't go down this path, let the kernel handle this kind of stuff.

> Oh really, where ?
>
> Let me show you why it can't be a module.

I'm not following. I haven't been talking about modules ...
(I think?)

Do you mean you want to show why it can't be in the kernel?

> In my case, I have a 2G modem connected to the soc :
>  - the modem and 1 SoC UART are connected (TX, RX, CTS, ...)
>  - the modem and SoC are connected through several gpios
>    - one or two control to power up and reset the modem
>    - one connected to the modem "ring" signal (the one I want a wakeup for).
>
> So I have no module to handle my modem :
>  - UART is handled by pxa-uart
>  - control/reset by gpiolib

Do you mean control/reset is handled by the userspace sysfs
interface to GPIOlib? This is not necessarily a good idea
in that case.

>  - ring ... by nobody
>
> So my point is that this ring *should* be handled by gpiolib, just as any casual
> input gpio. Moreover, the "wake-up" ability should be activable/deactivable on
> wish by userspace.

(...)

>>> Instead figure out how to make the subsystems we have and the
>>> device trees express what you want to do.
> As I said above, I don't think it's the way to go. I have *no* subsystem to
> address.

We have several cases of out-of-tree code due to missing subsystems.

One such subsystem is the in-kernel modem subsystem which Arun
has been trying to get going:
http://marc.info/?l=linux-kernel&m=134881988212794&w=2

> Devicetree can't help in the toggle to "activate" or "deactivate" the wakeup
> upon this GPIO, can it ?

No, I'm just saying the connection between the device and the
GPIO tree shall be modeled in the device tree, especially since
this is obviously deeply embedded, soldered-on stuff and the
hardware set-up should be encoded in the device tree.

I am starting so suspect that the real issue here, which has
not been expressed so far, is that you think of this embedded
modem as a US Robotics 28K8 modem connected to a serial
port, and as something that should be handled by userspace.

Is there a silent assumption that "modem drivers must be in
userspace"?

This assumption is not necessarily true when the modem start
to connect wires like GPIO to work. There are modems using
other things than UART, such as HSI, for datapath. And modems
using in-kernel protocols like CAIF or Phonet for control.

I think you need to think about how we join this modem closer
with the kernel instead of trying to paper it over using userspace
GPIO.

>>> What do you think about this idea? [GPIO hogs]
> I don't yet know. Let me think this more over. I'd like some literature if you
> can provide (especially on LAKML).

It doesn't toggle any pins so it's not what you want anyway.

I think you want part of your driver in the kernel.

I think the dilemma faced by embedded modems need to
be considered thoroughly here.

Yours,
Linus Walleij

GPIO sysfs : set a wake source

[Robert Jarzmik]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Thu, May 16, 2013 at 9:39 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>
>>>> Don't go down this path, let the kernel handle this kind of stuff.
>
>> Oh really, where ?
>>
>> Let me show you why it can't be a module.
>
> I'm not following. I haven't been talking about modules ...
> (I think?)
> Do you mean you want to show why it can't be in the kernel?
My bad. Bad wording, I should have said "why it shouldn't be in kernel".

>
>> In my case, I have a 2G modem connected to the soc :
>>  - the modem and 1 SoC UART are connected (TX, RX, CTS, ...)
>>  - the modem and SoC are connected through several gpios
>>    - one or two control to power up and reset the modem
>>    - one connected to the modem "ring" signal (the one I want a wakeup for).
>>
>> So I have no module to handle my modem :
>>  - UART is handled by pxa-uart
>>  - control/reset by gpiolib
>
> Do you mean control/reset is handled by the userspace sysfs
> interface to GPIOlib? This is not necessarily a good idea
> in that case.
Exactly, all controlled through userspace sysfs.

Well, it's the agreed method for far, see [1].
Search [1] for the string "These are really lengthy and time consuming sequences".

>> Devicetree can't help in the toggle to "activate" or "deactivate" the wakeup
>> upon this GPIO, can it ?
>
> No, I'm just saying the connection between the device and the
> GPIO tree shall be modeled in the device tree, especially since
> this is obviously deeply embedded, soldered-on stuff and the
> hardware set-up should be encoded in the device tree.
OK, expressed in DT, why not.

> I am starting so suspect that the real issue here, which has
> not been expressed so far, is that you think of this embedded
> modem as a US Robotics 28K8 modem connected to a serial
> port, and as something that should be handled by userspace.
Yes, that's what I and others think for modem startup control ([1]) but not for
modem data path.

> Is there a silent assumption that "modem drivers must be in
> userspace"?
No, certainly not. The assumption is one though that this particular modem,
which is that old and simple, doesn't require a driver other than the uart SoC
driver.

> This assumption is not necessarily true when the modem start
> to connect wires like GPIO to work. There are modems using
> other things than UART, such as HSI, for datapath. And modems
> using in-kernel protocols like CAIF or Phonet for control.
These are far more modern modems than the one I'm talking of.
Mine is a Sagem X200 (I think, from board disassembly).

> I think you need to think about how we join this modem closer
> with the kernel instead of trying to paper it over using userspace
> GPIO.
Why ? I has only one UART and several GPIOs. What good would it be to add it in
kernel ?

>> I don't yet know. Let me think this more over. I'd like some literature if you
>> can provide (especially on LAKML).
> It doesn't toggle any pins so it's not what you want anyway.
> I think you want part of your driver in the kernel.
Which driver ? The Sagem X200 ?

> I think the dilemma faced by embedded modems need to
> be considered thoroughly here.
As I said, it's an "old" modem. And if by embedded you mean "embedded in the
SoC", it's not, it's a separate chip. The interconnect are the UART lines and
the GPIO lines (solder lines as you pointed out).


Cheers.

-- 
Robert

[1] http://archive.arm.linux.org.uk/lurker/message/20080612.101303.80e8bb8b.fr.html

GPIO sysfs : set a wake source

[Linus Walleij]

On Sat, May 18, 2013 at 11:18 AM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:

>> I think you need to think about how we join this modem closer
>> with the kernel instead of trying to paper it over using userspace
>> GPIO.

> Why ? I has only one UART and several GPIOs. What good would it be to add it in
> kernel ?

Because of the Subject: of this email.

You are starting to set up interrupts and wakeup sources and
other kernel proprietary stuff from userspace and basically (IMO)
trespassing on kernel territory.

>> I think the dilemma faced by embedded modems need to
>> be considered thoroughly here.
>
> As I said, it's an "old" modem. And if by embedded you mean "embedded in the
> SoC", it's not, it's a separate chip. The interconnect are the UART lines and
> the GPIO lines (solder lines as you pointed out).

I do not worry about the age of the modem. I would have thought
the same if you took the PCB out of a Robotics 28K8 and soldered
it onto some chipset and soldered a wakeup line on a GPIO pin.

I worry about userspace getting to know everthing about interrupts
and wake up sources and it just IMO *shouldn't*. I don't think
userspace should know anything about IRQs beside /proc/interrupts
but I'm CC:ing tglx so he can say something here.

Yours,
Linus Walleij