Opened 10 years ago

Closed 10 years ago

Last modified 20 months ago

#1060 closed enhancement (fixed)

Autonomous mode operation for Marvell USB 8388

Reported by: rchokshi Owned by: rchokshi
Priority: blocker Milestone:
Component: hardware Version:
Keywords: power Cc: GR-Wireless-OLPC@…, mbletsas@…, javier@…, marcelo@…, richard@…, wad
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no


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.

Change History (10)

comment:1 Changed 10 years ago by andrey

Hi Ronak. I am not sure that the driver would need access to GPIO-2, it seems that would be a lower-level interrupt handled by a different component that would then wake up the system (and the driver). The OLPC does not use ACPI (as I understand it), but the Kernel provides a standard Power Management Subsystem, to which we will hook the driver to receive power management events.

comment:2 Changed 10 years ago by rchokshi

If it would be a low-level interrupt which would then wake up the driver, it should be OK. I guess the point that I was trying to get across is that when the host driver is woken up, it should be ready to submit the appropriate URBs to the USB HC and not initialize from the point of firmware download.

comment:3 Changed 10 years ago by jg

  • Cc wad added
  • Milestone changed from Untriaged to BTest-3
  • Priority changed from normal to high

comment:4 Changed 10 years ago by jg

  • Component changed from wireless to hardware

comment:5 Changed 10 years ago by rchokshi

Further, the possible scenarios in which the firmware would wake up the host are as follows:

  • Wake host up on non-unicast data
  • Wake host up on any unicast packet

It would be possible to select just one out of the above conditions. More conditions can be added as seen fit by OLPC.

comment:6 Changed 10 years ago by jg

  • Keywords power added
  • Verified unset

When is a firmware drop that implements this coming?

comment:7 Changed 10 years ago by jg

  • Priority changed from high to blocker
  • Verified unset

This should have been marked as a blocker for B4; it has been the goal for quite a while.

Requires bug #1594 to be fixed (now fixed).

comment:8 Changed 10 years ago by kimquirk

  • Milestone changed from Trial-2 to BTest-4

I moved all bugs from B4 to Trial-2; this one belongs in B4 so I moved it manually.

comment:9 Changed 10 years ago by jg

  • Resolution set to fixed
  • Status changed from new to closed

OK, this is in the 406.x series for B4.

I'm closing this one: please open more specific bugs on remaining issues, which I gather there are a few.

Thank you all for doing something not previously done on any system!!!! Congratulations to you all!!!!

comment:10 Changed 20 months ago by Quozl

  • Milestone BTest-4 deleted

Milestone BTest-4 deleted

Note: See TracTickets for help on using tickets.