<Wizzup>
BlagovestPetrov[: wants to try it on the d3
<uvos>
Wizzup: no i havent finished the combination yet
<uvos>
im not sure on what to do about android 4.1 bionics
<uvos>
speaking of witch
<uvos>
"<huckg> I'm still having trouble with droid bionic; I am on step 8 of https://github.com/IMbackK/bionic-clown-boot and getting Sending 'mbm' (256 KB) FAILED (remote: 'unsupported command') despite having upgraded to latest Android platform-tools as uvos suggested."
<uvos>
huckg: if you read the logs: i dont really know whats up with your device so your trying "fastboot flash mbm allow-mbmloader-flashing-mbm.bin", "fastboot --version" gives you "fastboot version 31.0.3-android-tools" or later your allow-mbmloader-flashing-mbm.bin has sha1sum of e44585ce14524e366df485f2784a0acc49d396c8 and your bootloader version, as displaied on device in fastboot mode is 0A.72 or 0A.78 right?
<Wizzup>
uvos: yeah I get freezes within minutes of interacting with the device
<Wizzup>
uvos: I'll have to check and see what happens if I don't detach kerne lconsole
<uvos>
Wizzup: ok
<uvos>
on thing to check might be the EMIF registers on android vs on leste (at load) and compear it with d4
<uvos>
catching it on serial is a good mission too ofc
<uvos>
as it testing with idle states disabled
<uvos>
i also wonder if the hangs happen
<uvos>
if you kexec to kernel 3.0.8 (ie safestrap) and then kexec to mainline
<uvos>
maybe the old kernel's inialization state is tripping us up
<Wizzup>
yeah, could be for sure
<Wizzup>
uvos: I am also seeing a delay on the d4 to detect it is discharging
<Wizzup>
at least in upower
<uvos>
some delay is expected
<uvos>
the ramp up takes about 1s
<uvos>
and the battery is reported charging only when its compleate
<Wizzup>
ok
<Wizzup>
it took maybe 30+ s or so
<Wizzup>
which is I think the upower poll interval if it gets no other info
<freemangordon>
Wizzup: uvos: or, maybe I shall stop spending time on omap DDX and get back to our initial plan now fence bug is fixed: modesetting/glamor (or replacement)
<Wizzup>
I don't think that makes sense atm
<freemangordon>
for missing rotation support: now I understand way better what omapdrm is doing, so I will fix dma_buf support there to allow rotation through TILER/VRFB for dma_buf BOs as well
<freemangordon>
Wizzup: not atm, for sure
<Wizzup>
check @ rotation
<freemangordon>
but, shall I spend more time trying to fix various bugs (like what uvos and you report)?
<Wizzup>
freemangordon: I mean if we have ddx working well and we think we want to go to for modesetting eventually we can do it of course, I just wouldn't suggest we abandon what we have now since it works well
<Wizzup>
I think yes
<Wizzup>
because we want to push these ddx to stable
<Wizzup>
and the droid4 has twice in the last few days hit this bug where X dies and the screen doesn't want to go on
<Wizzup>
because of this resource exhaustion thing
<freemangordon>
I understand, but I am not sure CMA/TILER bugs are easy to fix, even if possible
<Wizzup>
mm
<freemangordon>
IIUC, on d4 the issue is that TILER/DMM space gets fragmented with time
<freemangordon>
and I see no way to fix that
<freemangordon>
the same happens with CMA on n900
<freemangordon>
do you have any idea how to fix such an issue?
<freemangordon>
I am not going to implement DMM compaction algo in omapdrm
<Wizzup>
freemangordon: what about reusing buffers and not allocating on the fly?
<uvos>
cant we fix tiler fragmentation by just allocating once
<uvos>
?
<uvos>
d4 isent hurting for ram so mutch
<freemangordon>
what about rotation?
<uvos>
or tiler space afaik
<uvos>
freemangordon: just allocate a block thats 960x960?
<freemangordon>
HDMI?
<uvos>
hdmi dosent rotate
<uvos>
generaly
<freemangordon>
it does
<uvos>
so allocate a new one then
<freemangordon>
exactly
<uvos>
why would hdmi rotate
<uvos>
ie why would you want to do that often
<freemangordon>
forget about hdmi
<freemangordon>
I am not sure you can allocate 960x960
<uvos>
why not
<uvos>
its smaller than 1080p and that works ok allready
<freemangordon>
because OMAP DDX passes different flags depending on whether it is rotated or not
<freemangordon>
actually different functions are called
<freemangordon>
omap_bo_new vs omap_bo_new_tiled
<uvos>
2 questions
<freemangordon>
not to say omap ddx does not support dri3
<uvos>
thats not so important for now
<freemangordon>
sure
<uvos>
1. how dose tiler space get fragmented anyhow, we are the only ones allocating something there, so if we deallocate all buffers and then allocate new ones how dose fragmentation occure
<uvos>
2. why did ddk1.9 that did use the tiler (look at the allocations) work without problems
<freemangordon>
1: actually DMM is used for *every* buffer on d4
<freemangordon>
so, we allocate from TILER for scanout rotated buffers and from DMM for all other buffers
<uvos>
ok
<freemangordon>
so, most-probably the allocation taht fails is DMM allocation
<uvos>
but tiler space seams safe
<uvos>
just ddm then
<uvos>
*mm
<freemangordon>
yeah
<uvos>
and ddk1.9 did blits everywhere right
<freemangordon>
wait
<freemangordon>
DDK is TILER basically, like, they share the same address space
<freemangordon>
you just set different properties
<freemangordon>
so, fragmented DMM *is* fragmented TILER
<freemangordon>
there is DMM/TILER map in /sys/kernel/$somewhere, so Wizzup may want to look at it after some usage of his device
<uvos>
yeah i know
<uvos>
looks like irc.txt lost alot of stuff
<uvos>
i was just greping for that
<freemangordon>
uvos: not sure why ddk 1.9 works
<freemangordon>
it is using 3buffer as well
<freemangordon>
maybe I introduced some bug in OMAP ddx with regards to 3buffering
<freemangordon>
Wizzup: could you disable TripleBuffer in xorg.conf and check if is still crashes
<freemangordon>
1. dri3 for free. this will fix also the Xorg crashes we are seeing now as buffers are allocated only once in Xorg. A client unable to allocate a buffer will not bring the whole OS down
<uvos>
freemangordon: so tiler map shows more allocations now than it did in ddk1.9
<uvos>
1 vs 3 buffers looks like
<uvos>
not sure if relevant
<freemangordon>
sure it is
<freemangordon>
wait, this is in landscape?
<uvos>
yeah
<uvos>
the number of buffers dosent look like it changes in ddk1.9
<uvos>
it just changes reprisentation in the map (not sure how to read exactly)
<freemangordon>
could you disable 3buffer and see if it makes any difference?
<sicelo>
"why are those not in mainline linux?" - afaik they will be. it's just there have been a lot of PP kernel forks for a while, leading to massive fragmentation. now people are finally working on it together, with aim to have one cross-distro kernel. should be easier to mainline
huckg has joined #maemo-leste
<sicelo>
what was that device that had smartphone form factor, but didn't have a modem? Leste was also mentioned in its pages. I forgot the name now
<Wizzup>
the finnish thing?
<Wizzup>
necunos?
<sicelo>
yeah. thanks! i wonder what happened to them
System_Error has quit [Ping timeout: 276 seconds]
System_Error has joined #maemo-leste
System_Error has quit [Ping timeout: 276 seconds]
System_Error has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
huckg has quit [Quit: Client closed]
<uvos>
Wizzup: btw so can we enable charge-mode by default for some devices now
<uvos>
Wizzup: also since the n900 problem is fixed i think we should add sphone to meta on devel