<freemangordon>
yeah, now I can move to non-CMA allocated buffers so n900 to be usable with 5.15
<Wizzup>
great :)
<Wizzup>
I need a bit of a great from all the kernel stuff (day or 2), but then I'll check out more pm stuff and some of the replies on the ML
<Wizzup>
a bit of a break
<Wizzup>
seems the word great is stuck somewhere
<freemangordon>
mhm
<freemangordon>
if we only can find someone to look into xorg ddx :(
<freemangordon>
I wonder if we can find armsoc ddx devs and ask for help
inky_ has joined #maemo-leste
sunshavi has quit [Remote host closed the connection]
_inky has quit [Ping timeout: 268 seconds]
mepy_ is now known as mepy
sunshavi has joined #maemo-leste
sunshavi has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
_inky has joined #maemo-leste
sunshavi has joined #maemo-leste
linmob has quit [Ping timeout: 240 seconds]
linmob has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
uvos__ has quit [Ping timeout: 260 seconds]
uvos__ has joined #maemo-leste
joerg has joined #maemo-leste
inky has joined #maemo-leste
_inky has quit [Ping timeout: 260 seconds]
inky_ has quit [Ping timeout: 250 seconds]
<freemangordon>
tmlind: do you know if there is irc channel for openpvrsgx project?
_inky has joined #maemo-leste
<freemangordon>
as it seems my patch went into the void or was ignored, in either case I would like to know what happens
<bencoh>
there used to be #powervr on freenode, but iirc that was the old opensource driver channel (which wasn't very activem obviously)
<bencoh>
oh, actually we have #powervr on libera, with the usual suspects joined there, but it's not active either
<bencoh>
freemangordon: ^
alex1216 has joined #maemo-leste
<freemangordon>
great, thanks!
<Wizzup>
freemangordon: the ML might be a better place
<Wizzup>
bu you can try irc
<freemangordon>
I've send even ping on the ML
alex1216 has quit [Quit: WeeChat 2.3]
uvos__ has quit [Remote host closed the connection]
<tmlind>
freemangordon: not much any activity on the powervr channel, and hns only reads emails
<tmlind>
uvos: interesting, i accidentally did ifup wwan1 with modem configured to gsm and seem to have about 61 - 67 mW idle on d4 with modem online..
<tmlind>
uvos: i mean modem online but also with network connectivity up over modem
<bencoh>
nice I'd say :)
<tmlind>
yeah.. i recall with 3g and wwan1 up it was easily over 120 mW or something like that the last time i tried
<bencoh>
gsm is admittedly friendlier battery-wise yes
<bencoh>
(something about TDM/FDM vs CMDA)
<bencoh>
CDMA*
<tmlind>
not sure if accidentally doing qmi --nas-set-system-selection-preference=gsm caused this
<bencoh>
ah
inky_ has joined #maemo-leste
<tmlind>
bencoh: but gsm voice online consume at least the same as gsm voice + data right now..
<tmlind>
maybe the data connection actually now limits the modem from doing endless network scans or something :)
<bencoh>
"gsm voice online" meaning during call? and what is "gsm voice + data" then?
_inky has quit [Ping timeout: 250 seconds]
<tmlind>
bencoh: no gsm voice online meaning just voice modem connected to the network with no call active
<tmlind>
data meaning i can ping
<bencoh>
so are you saying it's about the same, or that data on really gives better results?
<bencoh>
(from my experience on n900, it should be pretty much the same, except in case of actual network activity)
inky has quit [Ping timeout: 250 seconds]
<tmlind>
yeah ok, maybe only 3g data consumes more power all the time
<tmlind>
also with v5.15 kernel, looks like the ifup wwan1 with pre-up qmi-network i posted here earlier works but not every time
_inky has joined #maemo-leste
pere has quit [Ping timeout: 250 seconds]
<Wizzup>
tmlind: hm, I think uvos and I see quite a bit more, but I suppose we might have more subsystems active
<Wizzup>
I should replace the d4 on this lab psu since it has some hw problem that makes it use a lot more power
<tmlind>
Wizzup: hmm i put cpu1 offline when i blank the screen, maybe give that a try?
<tmlind>
that seems to get rid of the constant ipi traffic
<Wizzup>
ok, will try that now
<tmlind>
i also have this looks like:
<tmlind>
echo 600 > /proc/sys/vm/stat_interval
<Wizzup>
my device is in 3g btw, and I think m-l generates quite a bit of debug (and thus mmc) traffic on modem signal strength, although we (should be) disabling that upon screen off
<tmlind>
ok, will check my power consumption with 3g again at some point, don't want to mess with it right now, expecting a package..
<Wizzup>
heh, makes sense
pere has joined #maemo-leste
<Wizzup>
tmlind: I think that saves quite a bit (turning one cpu off)
<Wizzup>
will try to properly measure, but from sleep and droid4-pm it looks like it saves maybe 200mW?
<Wizzup>
20mW
alex1216 has joined #maemo-leste
<tmlind>
yeah so it seems
_inky has quit [Ping timeout: 250 seconds]
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 256 seconds]
_inky has joined #maemo-leste
Kabouik has quit [Remote host closed the connection]
alex1216 has quit [Ping timeout: 252 seconds]
uvos has joined #maemo-leste
<uvos>
tmlind: yeah i allways use wwan1
<uvos>
tmlind: i have no idea why that works best
<uvos>
the ipi interrupts are qutie silly yeah
alex1216 has joined #maemo-leste
<uvos>
we can probubly tune the scheduler to try and not have both cpus active when there is little load
<Wizzup>
hmmm ofono uses something else no?
<uvos>
Wizzup: ofono has never worked for me
<uvos>
except by extream massaging
<uvos>
by restarting it often etc
<uvos>
so no idea
<Wizzup>
can try later as well (need to make a list lol)
<uvos>
speaking of powermanagemnt we should maybe import androids interactive scaling govenor
<uvos>
i know its sortof a hack
<Wizzup>
it might just mostly be in mainline
<uvos>
sortof
<uvos>
the mainline version dosent have the pivitol hack :P
<uvos>
the pivitol hack being that it ramps up on ts events
<uvos>
no matter what
<uvos>
this avoids ui latency
<Wizzup>
heh
<Wizzup>
maybe we can turn off a core upon screen blank
<uvos>
sure
<uvos>
i could have mce do that as a hack
<uvos>
but really
<uvos>
the scheduler should be smart enough
<Wizzup>
yeah I am a bit surprised that it wouldn't do that by defaulty
<uvos>
maybe we can use cpuset to prevent kernel threads from running on the second cpu
_inky has quit [Ping timeout: 260 seconds]
<Wizzup>
yeah but that's not ideal imho
<Wizzup>
also it would need to be more than just kernel threads probably
<uvos>
i dont think our userspace dose very mutch
<uvos>
when ideling
<uvos>
but yeah its not ideal
<uvos>
but its somewhere between "sched is smart enougth" and "mce disables all cpus except cpu0 when display is off"
<Wizzup>
we'll also need to check that als and other iio stuff doesn't use more pm
<uvos>
in terms of suckyness
<uvos>
no
<uvos>
iio-sensor-proxy sits in select at all times
<Wizzup>
sure, but kernel could keep things alive when fd is open
<Wizzup>
or w/e is used
<uvos>
i closes all fds
<uvos>
too
<Wizzup>
really, how does it know?
<uvos>
its extreamly well behaved - i checked before porting mce over
<Wizzup>
or is that because mce stops talking to it
_inky has joined #maemo-leste
<uvos>
it knows if it has a dbus client
<Wizzup>
k
<uvos>
on bionic it dosent even poll the accell
<Wizzup>
I'm still going to block the modules just to make sure later on
<uvos>
when the device is on
<uvos>
and accel rotation is active
<uvos>
:)
<Wizzup>
maybe this is the mystery pm difference eh :P
<uvos>
no
<uvos>
but the sensor drivers may be misbehaving yeah
<uvos>
we should add the hw intterupts to the stm accell driver btw
<uvos>
the d4 chip also has the no polling feature
<uvos>
its just missing in the driver
<Wizzup>
all of this would be very valuable to write down somewhere imho