Teleconference information for software status meeting (today, 21:00 EDT Boston)

Marcelo Tosatti marcelo at kvack.org
Thu Apr 19 15:11:27 EDT 2007


On Tue, Apr 17, 2007 at 10:21:51PM -0400, Chris Ball wrote:
> >> On Tue, 17 Apr 2007 15:50:46 -0400, Jim Gettys <jg at laptop.org> said:
> 
>    > OLPC software teleconference.  Note also the action item list
>    > below.
> 
> Present: Andres, Jim, Ronak, cjb, Mitch Bradley, Richard Smith, Jordan, 
>          John Watlington.
> 
> New action items:
> 
> * AI:  Richard/Mitch to investigate SD resume if they get time.
> * AI:  Get Richard Hughes more involved with power management
>        conversations, userspace/policy decisions.
> * AI:  Andres to note C-series firmware depends on build386 or higher on
>        the Firmware wiki page.
> * AI:  Jim and Chris to discuss user accounts for backup tomorrow.
> * AI:  Jim to send mail to Maemo folks finding out what they're doing
>        with OOM situations.
> * AI:  cjb to check the "Establishing a Wiki Portal" wiki instructions,
>        then Jim to release them.
> 
> Status:
> 
> Suspend/resume:
>   * SD clock isn't coming back reliably/quickly enough on Linux resume,
>     but is okay in OFW.  Probably a Linux problem.  
>   * AI:  Richard/Mitch to investigate SD resume if they get time.
>   * An orthogonal SD problem is that the mmc and block layers exist
>     independently from each other, and we can't encode the mmc layer's
>     dependency on resume order.  Similar problem for mfgpt/gxfb.
>   * Resume time has come down from 223->160ms!
>   * Need a status update from Marcelo on USB resume.

Still doesnt work reliably. I've made some progress by doing the
entire reset/reinit cycle instead of simply starting from USB RESUME
operational state: now the ports seem to be able to report card
addition/removal events, but they don't fully work (eg: storage cards
report READ CAPACITY FAILED).

I won't be able to work very much on it until the mid of next week when 
I go back go Brazil (bunch of events for the past and current week).    

>   * We need a userspace power manager daemon soon!

Yeah, like yesterday. 

>   * We need to make a bunch of policy decisions: 
>     * Need to expose wakeup event sources (lid, power button) to
>       userspace.  Lots of people want us to do it in different ways;
>       we should have someone working on userspace get involved too.
>     * AI:  Get Richard Hughes more involved with power management
>            conversations, userspace/policy decisions.
>     * We still have a flurry of userspace activity on wakeup as devices
>       reappear and are probed by hal/NetworkManager.

Right, my feeling is that this problem should be dealt with by power
manager daemon (its mainly networking devices that cause havoc).




More information about the Devel mailing list