Want IRQ on power/battery status change.

[dwmw2]

Polling is bad. We have to wake the CPU for it. We should get an interrupt when AC power is removed or applied, when status bits change in the battery status, etc. Perhaps even when the percentage charge changes.

[mfoster]

The PCBs are already being fabricated. Folks will either need to come up with a path that uses the existing EC communication mechanism, or else wait until B-Test2. Sorry!

[ray.tseng@…]

This is what ACPI does: (through 0x62/0x66 port) 1) EC detects the AC/battery insert/remove or battery percentage change, it assert EC SCI 2) OS get a SCI. If it comes from EC SCI then it will send query embedded controller(QR_EC) command (0x84) to EC 3) EC will place a notitification byte in output buffer 4) OS get the notification byte and run the relative _Qxx to process it ACPI sample code Device(EC0) { Name(_GPE,0x9) //EC SCI connect to GPE.9 …. Method(_Q08) {Notify(\_SB.AC, 0x00)} //AC in/out //Method(_Q09) {Notify(\_TZ.THRM, 0x80)} //Thermal Method(_Q0B) {Notify(\_SB.BAT0, 0x80)} //Batt in/out Method(_Q0C) {Notify(\_SB.LID, 0x80)} //Lid close //Method(_Q0D) {Notify(\_SB.SLPB, 0x80)} //Hotkey //Method(_Q0E) {Notify(\_SB.PWRB, 0x80)} //CM pwbtn }

For OLPC design

1) We can still use the SCI for the interrupt (BIOS program correctly) 2) Define an query interface (0x62/0x66, 0x68/0x6c, or others?) 3) Define a query command to get the notification byte (AC in/out...), we should consider more about Lid close... 4) If it's battery related event, then battery driver retrieve the battery information 5) Define the retrieve interface(0x380/0x381, or others)

[jg]

Dave, somehow this got assigned to me.

Is Ray's proposal adequate?

If not, please define something we and Ray can live with.

[JordanCrouse]

I dropped the ball on this one - I've been waiting for an interface for the hall effect sensors, and here it was under my nose the whole time. Using the SCI is a perfect solution - we can program the interrupt and query the status bits accordingly. The only thing I would ask is that we have a way to mask the events so that we could use events such as the lid open/close event as a wake event while blocking mundane, non wake events such as battery status. What do we need to do to make this happen?

[JordanCrouse]

I put code into our power patch to set up and use the SCI line from the EC on GPIO27 on the CS5536 so we have the example ready to go. That code will be in the olpc-2.6 tree as soon as we're done with B2. With the way that the CS5536 worked would really prefer that we keep the SCI line for true power events (especially wake events) - If there are any non power / wakeup related events that you want to communicate, is it possible to use the SWI line instead?

[JordanCrouse]

One of the EC SCI wake events should should be 'wireless event' as per #679.

[rchokshi]

Replying to JordanCrouse:

One of the EC SCI wake events should should be 'wireless event' as per #679.

I came across this trac issue and would like to mention that we are incorporating the capability to factor-in the battery condition of the laptop in the metric calculations for the forwarding table for every next hop. This has been under discussion with Michail since a long time now. Here is what we have been discussing with Michail so far:

The calculation of metric uses the battery information available from the host. This information is primarily available from the GPIO connections on the Marvell USB 8388 module. GPIOs [13:15] are used for this and are connected with the EC. The values coming from the EC on the GPIOs are assumed to:

- high level: 1 - low level: 0

We are also assuming for now that the output from GPIO [13] will be the LSB. Hence, the output coming from GPIO[13:15] will form an integer value 0 - 7. The lower the value the lower the battery power. This value as mentioned above will be factoring in the formula for metric calculation. We are assuming that these GPIOs would be controlled by the battery driver. I am assuming that the battery driver will need some modification for this but I am not sure if the above is already thought about. The frequency of the battery driver output on the GPIOs are assumed to be of the order to 1 – 5 seconds.

The hardware connections for this are done already starting from A-test, I think.

Please let me know if this sounds appropriate to everyone.