[Trac #1060] Autonomous mode operation for Marvell USB 8388

[Zarro Boogs per Child]

#1060: Autonomous mode operation for Marvell USB 8388
-------------------------+--------------------------------------------------
 Reporter:  rchokshi     |       Owner:  rchokshi 
     Type:  enhancement  |      Status:  new      
 Priority:  normal       |   Milestone:  Untriaged
Component:  wireless     |    Keywords:           
-------------------------+--------------------------------------------------
 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.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1060>
One Laptop Per Child <http://laptop.org/>