<Wizzup>
X also not happy: [289971.389] (EE) OMAP(0): ERROR: PVRSRVMapFullDmaBuf failed: PVRSRV_ERROR_BAD_MAPPING fd 264
<Wizzup>
seems like a high fd to me
<Wizzup>
freemangordon: latest kernel works for me (panel)
<Wizzup>
it's also smoother in 3d for sure
<Wizzup>
freemangordon: hm d3 seems to boot for me
<Wizzup>
freemangordon: d4 boots ok for me as well?
Pali has quit [Ping timeout: 240 seconds]
<mighty17[m]>
freemangordon: can you send 99-modesetting.conf again? the pastebin expired? :(
xmn has quit [Ping timeout: 240 seconds]
macros_ has joined #maemo-leste
macros__ has quit [Ping timeout: 268 seconds]
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
<mint[m]>
hey, not sure if this question goes in this channel but i'm having some issues with surf2. after clicking the URL box i can't use a text box in the web view, how can i stop highlighting the URL box?
<freemangordon>
Wizzup: seems somehow I managed to uninstall the kernel on my d4
<freemangordon>
I mean - I removed linux-image-droid4
<freemangordon>
but, this was after I installed linux-image-omap
<freemangordon>
reinstalling linux-image-omap fixed it
<freemangordon>
Wizzup: re that error - seems you are running out of DMM/TILES space somehow
<freemangordon>
Wizzup: so, ba9c85a6643f9fad15018390a3b59280187b7564. shall be removed and other fix found for high power usage
<mighty17[m]>
tysm
<freemangordon>
Wizzup: also, why do we carry a20f161298226a368d73af1b1467568ba5d05efa?
huckg has quit [Ping timeout: 256 seconds]
Pali has joined #maemo-leste
Langoor has quit [Ping timeout: 256 seconds]
Kabouik has quit [Remote host closed the connection]
Kabouik has joined #maemo-leste
Kabouik has joined #maemo-leste
Kabouik has quit [Changing host]
Langoor has joined #maemo-leste
<tmlind>
freemangordon: your dmabuf fix also fixes my wlroots termite test case even with sgx clock slowed down :)
<tmlind>
freemangordon: also, did you update the ddk blobs branch? seems like your blobs changes caused the environment regression somehow if i remember right?
<tmlind>
hmm or am i confused again on what caused the environment variable needed regression?
<tmlind>
i guess it must have been a mesa change instead..
<tmlind>
spotty connection, bbl
<Wizzup>
freemangordon: regarding a20f161298226a368d73af1b1467568ba5d05efa - uvos said to keep it for charge mode iirc
joerg has quit [Read error: Connection reset by peer]
_uvos_ has joined #maemo-leste
<_uvos_>
freemangordon: "ok, you can start charging immediately and then bring-up whatever UI is needed"
<_uvos_>
i thin you missunderstood this
joerg has joined #maemo-leste
<_uvos_>
the problem isent starting charging
<_uvos_>
its that usb power can not keep d4 alive it uses to mutch
<_uvos_>
it must enter idle asap
<_uvos_>
and the bootloader gives little room here
<_uvos_>
it boots the device just after the battery has bearly enough charge to enter androids charge mode
<_uvos_>
wich is very quick
<bencoh>
I'm not sure the bootloader would enter idle anyway (vs busy-waiting)
<bencoh>
but I haven't checked, so I dunno
<_uvos_>
the bootloader sets cpcaps idle regs
<_uvos_>
er trickel charge regs
<_uvos_>
and shuts off
<_uvos_>
cpcap then boots again
<bencoh>
ah
<_uvos_>
after a set voltage
<bencoh>
nice
_uvos_ has quit [Ping timeout: 240 seconds]
* sicelo
will probably now start using Leste/Droid 4 more, now that he has a somewhat better battery. at around 20 hours now, and still has 3.6v. calibration not finished yet, but definitely feels better than the 700mAh I had all along
<freemangordon>
_uvos_: I think I understand it right. "bring-up" of the UI after battery is charged enough to allow it
<freemangordon>
also, I am sure we can power off all but CPU0, and put CPU0 @ lowest frequency
uvos has joined #maemo-leste
<freemangordon>
This should be enough to support minimal UI (like alarm/charging one) with radios off
<uvos>
probubly
<uvos>
unsuprisingly i like the architecture that i desinged for charge mode :P
<uvos>
anyhow ill move it to drm soon
<freemangordon>
no, it sounds fine, what I am saying is that we shall extend it (if needed) to support alarm
<uvos>
probunly i can do it tomorrow
<uvos>
sure
<freemangordon>
uvos: also, I am almost sure battery holds enough charge so matchbox to be started
<uvos>
no
<freemangordon>
hmm, ok
<uvos>
so in the deepest discharge state we are allready in the hole
<uvos>
when sysinit finishes
<uvos>
because of kexecboot
<uvos>
that takes extra time
<freemangordon>
I see
<uvos>
relatvie to android native
<uvos>
so we allready have to move charge mode into initramfs
<uvos>
at some point
<freemangordon>
yeah, so we shall hold a bit in charge-only mode
<uvos>
yeah somehting like that
<freemangordon>
until we have lets say 2% (made-up) value
<uvos>
sure
<freemangordon>
and then proceed to charge-only-phase2
<freemangordon>
and here the switch shall be made to alarm, user, unplug, no?
<uvos>
yeah
<uvos>
thats how it currently works
<freemangordon>
ah, nice
<freemangordon>
for how long it stays in charge-only mode?
<uvos>
untill sone of those switches is tripped
<uvos>
(or its full)
<uvos>
*s/sone/one
<freemangordon>
another note - do you say that with everything but cpu0 and mmc omap4 uses more than 500mA?
<freemangordon>
*everything off
<uvos>
no idea probubly not
<freemangordon>
so, *in theory* we may boot to alarm even if we don;t have minimum charge
<uvos>
maybe
<freemangordon>
cool
<uvos>
the problem is,currently during boot its too mutch
<uvos>
before userspace even starts
<uvos>
so fix would have to be in kernel somehow
<uvos>
or avoid loading so mayne modules
<freemangordon>
hmm, maybe we shall load modules manually
<uvos>
and have a inintramfs with just cpcap-carhger to dwel in
<uvos>
*charger
<freemangordon>
I think we shall try to avoid initrd if possible
<freemangordon>
not really sure how this can be achieved
<uvos>
im pretty neutral on having a initramfs
<freemangordon>
well, my point is that this is yet another thing to maintain :)
<freemangordon>
if we can avoid...
<freemangordon>
but we'll have to find a way to delay module loading until some condition is made
<uvos>
yeah
<uvos>
anyhow its not that important to fix this rn
<uvos>
mce now shutsdown the device well ahead of the problem area
<uvos>
so you should only be albe to enter it by leaving the device in cupboard for a long time
<uvos>
or leste hanging or something
<freemangordon>
my point was about bootup
<uvos>
and even then you can just use androids charge mode
<freemangordon>
but yeah, a corner case
<uvos>
freemangordon: yes i know
<uvos>
freemangordon: im saing this problem is farly small
<uvos>
atm
<freemangordon>
:nod:
<bencoh>
freemangordon: don't we already use devuan's initramfs?
<uvos>
no
<bencoh>
(I agree with maintaining an initramfs being a burden btw)
<bencoh>
if we really want to we could probably blacklist modules in /etc/modprobe.d/ and insmod it manually
<bencoh>
(it sounds kinda ugly though)
<freemangordon>
uvos: what about having modprobe.d file that blacklists all the modules and later on, when we don't need it anymore, we can bindmount to an empty file?
<freemangordon>
bencoh: see ^^^
<bencoh>
:)
<uvos>
sure but i agree its really ugly
<freemangordon>
would that work?
<uvos>
we could have a runlevel that avoids running udev instead
<uvos>
and modprobes just cpcap modules
<uvos>
and then dwels
<bencoh>
probably, although bindmounting sounds even worse to me that manually insmoding
<uvos>
and then runs normal sysinit
<freemangordon>
ah, so it is udev that does modprobe?
<uvos>
yeah
<freemangordon>
good
<freemangordon>
well yeah
<bencoh>
we can just add a udev rule then
<freemangordon>
bencoh: nor, really, not starting udev is better
<freemangordon>
*no
* bencoh
headscratches
<freemangordon>
we build whatever we need in zImage
<freemangordon>
for minimal system
<uvos>
sure
<freemangordon>
that does charging only
<uvos>
that probubly helps start charging sooner too
<freemangordon>
mhm
<bencoh>
(btw at $job bootloader prevents booting (ie waits) until battery is "charged enough")
<freemangordon>
and once we have enough charge, we start udev or $whatever_is_needed
<freemangordon>
like swithing the runlevel
<freemangordon>
*switching
<freemangordon>
I think that way we avoid initrd
<bencoh>
oh right, using a different runlevel sounds like a decent idea
<freemangordon>
uvos: we may want to fix getbootstate to fi that new boot logic
<uvos>
whats this?
<freemangordon>
a tool that gets boot state, like USER, ACTDEAD, MALF
<uvos>
from atags?
<freemangordon>
yes
<uvos>
ok
<freemangordon>
I know you hate it, but we shall keep ACTEAD (in some shape) at least for a while
<freemangordon>
there is too much code that relies on env var being set
<uvos>
so currently chargemode just checks if the usb cable is plugged in (and assumes that this means we should enter charge mode) and with the hwclock
<uvos>
on mapphones we cant asses the boot reason
<uvos>
the android kernel has cleard it before we can kexec
<uvos>
the good thing about this method is also it works everywhere
<uvos>
ie currently on maphones and pp and n900
<freemangordon>
yeah, sounds fine
<uvos>
the bad thing ofc is that the user might press the power button
<uvos>
then insert the cable
<freemangordon>
while on charger?
<freemangordon>
ah
<freemangordon>
yeah
<uvos>
and it will enter charge mode erronously
<uvos>
not a big deal of the user will just press the power button again
<uvos>
but a bit wonky
<freemangordon>
yeah
<uvos>
and at least on maphones we cant do better
<freemangordon>
not a big issue I would say
<freemangordon>
though, I think on OMAPs at least there is some memory location with flags about the boot reason
<freemangordon>
ah, but android kernel clears that
<freemangordon>
I see
<freemangordon>
well, we do the best we can
<freemangordon>
then
<freemangordon>
uvos: basically, ACTDEAD means we have /tmp/ACT_DEAD :)
<freemangordon>
and also ACT_DEAD in /tmp/mode (or something
<freemangordon>
alarm plugin already supports that, and if device was woken-up by an alarm, after you snooze/stop it, you are asked if you want to power-on the device
<freemangordon>
also, XSession already supports actdead mode, like different set of applications is started
pere has quit [Ping timeout: 240 seconds]
<freemangordon>
Wizzup: what is hildon-kernel-config-n900 ? hildon-meta-n900 depends on it
<freemangordon>
Wizzup: OTOH lates kernel seems to boot fine on both d4 and n900
<Wizzup>
20:39 < freemangordon> Wizzup: what is hildon-kernel-config-n900 ? hildon-meta-n900 depends on it
<Wizzup>
freemangordon: this is the uImage postinst
<Wizzup>
freemangordon: yes, also boots ok for me
<freemangordon>
can't be as it is neither installed nor available :)
<freemangordon>
leste-config-n900 is postinst :p
<freemangordon>
Wizzup: I think you initially planned to have that additional package
<freemangordon>
but later on we decided to move postinst to leste-config-n900
<freemangordon>
so I thing this dependency is not needed
<freemangordon>
Wizzup: I think I fixed sgx-ddk-um dependencies
<Wizzup>
freemangordon: no, we decided not to go the leste-config route
<freemangordon>
OS error code 16: Device or resource busy
<freemangordon>
this should not happen
<Wizzup>
freemangordon: n900?
<freemangordon>
yes
<freemangordon>
happened twice, during heavy IO
* freemangordon
checks how is memory allocated
<Wizzup>
uvos: so do you still not get d3 hangs?
<uvos>
Wizzup: so i just came home
<uvos>
the uptime of my d3 suggests it dident crash
<uvos>
but it ussaly hangs while using it
<uvos>
i wasent able to test the other day actively more than when i said it dosent seam to crash
<uvos>
that was just a couple of hours
<uvos>
so maybe
<uvos>
if it dident help yours its just noise most likely
<uvos>
even it it dosent help with the current hang, i would keep the patch in mind, but maybe not applied
<uvos>
since clearly motorola thought it needed at some point, and d3's microcode/fw is so mutch older than d4
<uvos>
where they obviously patched it out
<Wizzup>
right
pere has joined #maemo-leste
<freemangordon>
Wizzup: maybe I shall change DDX to retry allocations until memory is available
<uvos>
that can cause an undesirable deadlock no?
<freemangordon>
not really
<freemangordon>
because we definitely have free CMA memory, it is just that *now* there are too many pages that cannot be migrated
<uvos>
sure
<uvos>
but do you know that?
<uvos>
what happens when something leaks cma
<freemangordon>
well, what can we do in such case? restart X?
<freemangordon>
I mean - if we have CMA leak, nothing can be done
<uvos>
x crashing with obvious messag in this case is mutch better than it hanging
<freemangordon>
but, this is not the case here
<freemangordon>
well, it can retry some time
<uvos>
also cant cma be filled becaue video decoding or whatever is using it
<freemangordon>
better that instant crash
<uvos>
sure yeah thats fine
<freemangordon>
we get -16, not -12
<freemangordon>
-EBUSY
<freemangordon>
this seems to be returned after 5 retries to free big enough memory block
<uvos>
ok
<freemangordon>
I am not sure __GFP_REPEAT is usable if passed to dma_alloc_wc
huckg has joined #maemo-leste
<Wizzup>
freemangordon: I wonder if something is leaking as well (wrt d4)
<Wizzup>
freemangordon: but makes sense to try
<freemangordon>
Wizzup: d4 does not use CMA
<Wizzup>
freemangordon: yeah
<Wizzup>
I know
<Wizzup>
btw n900 perf is great now imho
<freemangordon>
it is most-probably DMM/TILER that gets fragmented
<freemangordon>
yeah, but there is a place for improvement
<freemangordon>
we still lack HW accell for compositing
<freemangordon>
but will do it after abook etc
<freemangordon>
I wonder if I can just allocate a pool of 3 BOs in DDX and call it a day
<Wizzup>
mhm
<bencoh>
probably (why not?)
<Wizzup>
freemangordon: agreed @ boabook
<freemangordon>
we still can have issues on rotation though
<bencoh>
just allocate buffers large enough hold both orientations
<freemangordon>
well, too much unused memory
<bencoh>
if you use cma for that and are admittedly the only cma user ...
<freemangordon>
in theory we can have more CMA users, like DSP etc
huckg has quit [Quit: Client closed]
<bencoh>
sure
<freemangordon>
also CMA or not, this is still memory :)
<bencoh>
I mean, yeah, but ...
<freemangordon>
esp on n900 it is costly
<bencoh>
cma memory is not reclaimed for the rest of the system
<uvos>
so we are we stil going to be flipping application buffers on d4?
<uvos>
or are we blitting everywhere to save n900 cma
<bencoh>
so either you will need up to 3 buffers at some point
<bencoh>
and there is no downside to allocating it at boot
<bencoh>
or you don't, but then I don't see any reason to allocate 3 of those
<freemangordon>
uvos: honestly, I am not sure how it works, but judging by the allocations, we flip 3 buffers only. application windows are composited to those 3 it seems
<Wizzup>
uvos: clutter does not blit anymore
<bencoh>
I'm not sure I understood the fragmented DMM/TILER thing btw
<bencoh>
but I gotta go for now :)
<Wizzup>
expect blit rather
<freemangordon>
Wizzup: yes, but Xorg does
<freemangordon>
and basically we do blits to front buffer
<freemangordon>
Xorg does flips I mean
<freemangordon>
and it basically blits application buffers to the scanout buffer, unless application is in fullscreen
<freemangordon>
in which case I am not sure how many scanout buffers we have
<uvos>
i mean if the window is not fullscreen i dont see how you have an option except to blit
<freemangordon>
right
<uvos>
unles you use layers
<freemangordon>
not, it blits
<uvos>
but fullscren should flip
<freemangordon>
yes
<uvos>
unless n900 dosent have the ram
<uvos>
cma that is
<freemangordon>
anyway, I have to stop for today, need some sleep
<uvos>
night
<freemangordon>
night!
<uvos>
freemangordon: bug report btw:
<uvos>
freemangordon: xorg allways crashes when you chvt back to it