[Mer-discuss] Mer and SmartQ

[David Greaves]

Hi

Thanks for the info - I've snipped that and have a few follow-ons below:

You Sheng wrote:
> Hi David, 
> 
> 2009/9/25 David Greaves <david at dgreaves.com <mailto:david at dgreaves.com>>
> 
>     We are currently working on the XAA acceleration and video support
>     and I think
>     we have a breakthrough there too.
> 
> Is this branch? http://gitorious.org/mer/xserver-xorg-video-fbdev 
Yes

It depends on the kernel I'm working on which incorporates some other patches.
I'm testing it before I push it.


>     A new release of Maemo will be available soon and we've been busy
>     making sure
>     that we are ready for that - we are hoping to make some real
>     improvements to the
>     UI look and feel.
> 
> Great news, thanks for your guys hard working. Really appreciated.
Thanks. We hope that once we have that stabilised in a few weeks it will make a
sane base for you to consider for products.
If there is any software you want to incorporate into the Mer release then
please let us know.

>     We have a few areas we'd like to follow up on:
>     * MMC
>     There has been some discussion of MMC problems causing the internal
>     MMC to
>     become corrupted. Did this commit:
>     http://gitorious.org/mer-smartq/mer-smartq-kernel/commit/112a485fecdaeabe2b5fc7c1eea0832d2da26c0d
>     fix that or is there still an issue?
> 
> This is not a MMC patch, it only fix Q5/Q7 can't suspend which's memory
> chips provided by Mira.
OK.
Do you have any ideas why we've seen MMC corruption issues? One thought is that
the kernel is allowing the battery voltage to drop too low before powering down?


>     * Power consumption in Mer is not very good; any ideas?
> 
> On suspend or full power running? How many milliamp ? 
I've not measured at the hardware level; we're seeing battery life of just a day
whilst idling.

>     * Is there dynamic CPU voltage scaling? We'd like to understand how the
>     freq/voltage scaling works.
> 
> No CPU voltage scaling support. CPU freq scaling based on kernel cpufreq
>  subsystem, ondemand is the default cpufreq policy governor.
> arch/arm/plat-s3c64xx/clock.c is the scaling code.
OK. We'll take a look at that.


>     * Could we get schematics and/or a list of used electronics and
>     their GPIO
>     connections/I2C addresses/datasheets/... for the Q5 and Q7?
Anything on this?

David

-- 
"Don't worry, you'll be fine; I saw it work in a cartoon once..."