Bug 6727

We should allow for any and all of the available wake pins to be configured as such - individually.

I do not think native function F6 is what you want. (1) F6 is a native fuction which is connected to WAKE# signal of PCIe devices, which is routed to ACPI's PCIe GPE, rather than GPIO GPE. I think we still need to use GPIO F0. (2) And SUS0 does not have F6 function.

David, that sounds correct to me.

Firmware team update:
After (1)enabling edge detection and wake capability of GPIO_SUSx, (2)routing GPIO_SUSx to GPE GPIO_SUSx and (3)enabling wake capability of GPE GPIO_SUSx, GPIO_SUS0 (GPIO_S5[0]) could wake the system from S3 and S5. But the same code implementation cannot make GPIO_SUS1 and GPIO_SUS2 get the wake capability. Our team is debugging this isse.

This is a question, that since the pins go through a level shifter, is this even possible, or is this going to be a "known issue" that isn't really resolvable with the current board?

David Wei:

Please enable a menu to "Enable GPIO Wake" for each of GPIO_S5[2:0] to GPIO GPE (F0 I think you said).

From Linux, we enter the sleep states as follows (most distributions have GUIs for this, but the following always works):

S1:
# echo "standby" > /sys/power/standby

S3:
# echo "mem" > /sys/power/state

S4:
# echo "disk" > /sys/power/state

S5: (from wikipedia)
G2 (S5), Soft Off: G2/S5 is almost the same as G3 Mechanical Off, except that the power supply unit (PSU) still supplies power, at a minimum, to the power button to allow return to S0. A full reboot is required. No previous content is retained. Other components may remain powered so the computer can "wake" on input from the keyboard, clock, modem, LAN, or USB device.

I don't know how to enter S5 or how this differs from G3 (mechanical off).

Ivan, can you provide instructions for entering these states from Windows?

On Windows:

To find out supported S-states, launch CMD.EXE as Administrator and run:
POWERCFG -A

If S3 is not supported, make sure Intel Graphics is installed.
To enable S4 run POWERCFG -H ON

For S3:
Press Windows key + I, Click on Power and then Sleep

For S4:
launch CMD.EXE as Administrator and run:
SHUTDOWN.EXE /H

For S5:
launch CMD.EXE as Administrator and run:
SHUTDOWN.EXE /S /T 0

S5 is what we need, not G3 (G3 is board not powered - cannot wake from that).

We will first provide an engineering drop which gets all required registers programmed for GPIO_S5_0, so that CircuitCo can start to verify it as soon as possible. Meanwhile, we will add a setup option to enable/disbale this feature feature.

Created attachment 2254 [details]
Engineering drop for GPIO_S5_0

David Anders:
Can you test this Engineering drop for GPIO_S5_0 on your side? See attachment:"MNW2MAX1.X64.0074.R03.1411210910.zip". Thanks!

Information given, out of NEEDINFO

Created attachment 2284 [details]
Item"GPIO Wake Capability" for GPIO_S5_0

Currently, we add setup item "GPIO Wake Capability", which can enable/disable
GPIO_S5_0 for S3,by following setup option:Device Manager->System Setup->South Cluster Configuration->Miscellaneous Configuration->GPIO Wake Capability.
Test image,see "Item"GPIO Wake Capability" for GPIO_S5_0".

hi shifei,
I used the firmware in attachment 2284 [details] and enable the gpio wake up option,
but kernel gpio driver didn't work any more. So if I enable it, gpio will be selected to IO access instead of memory access right?

Weixing,
Yes,GPIO wake up is accessed by I/O access only.Which type OS included kernel gpio driver didn't work any more on your side?

Hi all,
I think the problem for gpio is the mmio and io register can't co-exist which means if i enable io access,
the mmio register was invalid and can't be read/write anymore.These two register set both have some functions
that the other one dont have, like io register can enable wake up function, but mmio didn't have.
You can configure the gpio pullup, pulldown or non pull state by acessing mmio register, but io register can't...
I really don't know why the gpio controller register was designed like this, fix me if I am wrong.

According to Intel public datasheet for Intel Atom processor E3800, When a GPIO is selected via the IO USE_SEL, Memory accesses are denied (pconf0, 
pconf1 and pad_val).  

Maybe you could try following bits to switch between IO and MMIO mode.


Register: 
Sus Use Select 1 (cfio_ioreg_SUS_USE_SEL_31_0_)—Offset 0h
Access via PCU Proxy, the register is setting the correspanding GPIO to be selected and to be changed to IO access instead of the default Memory access. Bit 0 will set 
GPIO[0], and bit 1 will set GPIO[1] and so on.

hi david,
The big problem is if I select io access, not only mmio access was denied, but also the configuration function provided by the mmio access register was invalid, seems like the mmio access register all reset to default value.

Updating assignee to new office e-mail address.

Hi all,

What we want to achieve is:
Considering from power-saving POV, we will try our best to put the minnow-max system into S3 once possible, after then, we will wake up the system to S0 if there would be something needed to do. So we are connecting one movement detection sensor to minnow-max by GPIO as wakeup source, and once the sensor found movement (like human's activities), the system will back to S0.

Now as Xing had mentioned before, if we use I/O way to set the wake-up capability of GPIO, we 'can' wakeup the system from S3 by GPIO "BUT" due to under that situation, the default value of GPIO is high, and we have no way to config high/low as MMIO way doesn't work now, and also have no way to pull it low enough by this sensor, so we always failed to wake up the system by GPIO.
Under this situation, the only way to wake-up system is connecting Pin to GND so the signal is low enough and can be identified by HW then wakeup the system.

We are trying to connect one resistance in this board so that by that same sensor, we also can get one 'low enough' value to GPIO pin.

But it is one ugly workaround obviously even be successful.

So, for our minnow-max, that means we DON'T have one decent way to wake up the system from S3 by GPIO?

P.S, we also try to wake up the system from S3 by w-o-wireless, but also failed. See bug#7109.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7109 

Any suggestions would be appreciated!

(In reply to comment #19)
one correction

- We are trying to connect one resistance in this board 
+ We are trying to connect one resistance to this sensor

We are no longer tracking in Yocto Project Bugzilla MinnowBoard and MinnowBoard-MAX HW and firmware bugs.