Ticket #1060 (closed enhancement: fixed)
Autonomous mode operation for Marvell USB 8388
| Reported by: | rchokshi | Owned by: | rchokshi |
|---|---|---|---|
| Priority: | blocker | Milestone: | BTest-4 |
| Component: | hardware | Version: | |
| Keywords: | power | Cc: | GR-Wireless-OLPC@…, mbletsas@…, javier@…, marcelo@…, richard@…, wad |
| Action Needed: | Verified: | no | |
| Deployments affected: | Blocked By: | ||
| Blocking: |
Description
I would like to open a ticket for this to make sure that everyone can see the details that will follow. What OLPC calls autonomous mode, we sometimes like to call host sleep mode - so you might see host sleep mode mentioned at many places below. We also have some comments/questions here as well.
The autonomous mode of operation for the XO means that when the host CPU alongwith most of the other on-board devices are shut off, the WiFi interface module should still be active, functional and be able to forward frames to the next best hop. The firmware wakes up host based on configured events through GPIO 2 on the Marvell 8388 SoC connected to the EC.
Question: The WLAN SoC will generate edge triggered active low (signal from high to low) interrupts to host. Is this is the right thing to do or should it be different, e.g. active high?
The OLPC driver needs to support the GPIO 2 logic in order to communicate with firmware. The driver may also need to support ACPI (Advanced Configuration and Power Interface) in order to be notified by Linux OS about system sleep/wake up events. This feature requires a detail coordination on the interface between driver and firmware.
The work items for this include: - Implement the Enhanced Host Sleep feature. Here is a brief description of interface between driver and firmware for this mode: (a) Driver issue HOST_SLEEP_CFG command to set the wake up conditions. (b) Firmware reply to HOST_SLEEP_CFG command. (c) Driver issue HOST_SLEEP_ACTIVE command. (d) Firmware reply to the command. Once driver get reply, it needs to inform host to enter sleep mode. (e) Firmware stop any transaction to driver and waits for a GPIO interrupt from host to confirm receive of reply at step (d), and detach device from USB bus.
Comment: We will also make arrangements to make sure that the Marvell USB device is detached from the USB bus at this point but for the initial design, we would like to keep it simple.
Question: OLPC needs to define a GPIO that will be used as input to the Marvell 8388 SoC for this. It will need to be wired appropriately to a GPIO on the Marvell side. We should be able to use any GPIOs other than GPIO [0-2], [6-7], [12-15] for this to serve as input to the Marvell 8388. Can someone take the action item here to select one of these GPIOs, inform us about the same and close the loop with Quanta?
(f) If one of the pre-configured wake-up conditions is met, firmware generates interrupt to host by GPIO 2. If host is at awake state, it need to ignore the interrupt gracefully.
Comment: At this point, the firmware will re-attach to USB bus before generating the interrupt to the host using GPIO 2 to complement for the comment in step (e) above.
(g) Firmware wait for “gap” requested by host if “gap” is not 0. The "gap" is a parameter in the HOST_SLEEP_CFG command. Once the USB module senses SOF, firmware send Host Wakeup event to host. (h) After driver wake up, it must submit URB (USB Request Block) to receive Host Wakeup event first, and then the 2nd URB to retrieve the actual wake up event. (i) Firmware sent the actual event/data which matches the wakeup condition. (j) Firmware deactivate host sleep condition. This serves as a complement to step (c). (k) Driver and firmware resume data Tx/Rx path. (l) The host can issue HOST_SLEEP_ACTIVE command to re-activate wake up conditions, or isssue HS_Config w/cancellation to remove wake up conditions. (m) After step (e), the host can generate GPIO interrupt through GPIO pin (to be defined by OLPC) to notify firmware if the host wants to resume data Tx/Rx command by itself. Note that the host must be at fully wake up state, including the driver being ready to receive packet from host controller, before it generates interrupt through GPIO. (n) Firmware confirm step (m) and wait for SOF from USB bus.
Comment: We will also re-attach the Marvell device back to the USB bus at this point.
(o) Firmware sends Host Notify event to driver to confirm the host notification. (p) Once step (o) is completed, the interface continues from step (j).
- Further task is debug/Unit testing with host driver on the XO. - Debug/test the GPIO line access logic.
