<Wizzup>
uvos darn we missed huckg, I guess he'll be back
cockroach has quit [Quit: leaving]
uvos has quit [Ping timeout: 256 seconds]
<sicelo>
I am now on my 3rd charge cycle with droid 4 and still battery isn't calibrated. What am I missing? I charge the device to full, then allow it to run empty, without any reboot or charging in between
<tmlind>
i don't understand why mesa could not just manage the /dev/dri directly, why is the libdbm needed there at all?
<tmlind>
freemangordon: no i don't have that patch yet, sounds like i should try with it
<freemangordon>
yes
<tmlind>
ok
<freemangordon>
tmlind: also, make sure to revert 6dd1aad1d0c4716944098b7b0f2abdd3a26cc0be and get fences patch
<freemangordon>
or, just use leste kernel tree :)
<tmlind>
yup, 6dd1aad1d0c4716944098b7b0f2abdd3a26cc0be should not be needed any longer at all after your fix
<freemangordon>
mhm
<freemangordon>
I wonder if we shall create a new branch/repo with all those obsolete patches not applied on the first place
<tmlind>
yup let's do that after v5.16 is tagged
<freemangordon>
ok, deal
<tmlind>
and backport your two fixes
<freemangordon>
backport? thay are done against 5.15 :)
<freemangordon>
also, I think they are more than two
<freemangordon>
at least 3 in omapdrm and 2 in pvr
<tmlind>
ok well backport as in these won't hit the mainline kernel until at v5.16-rc1 :)
<freemangordon>
ah, yeah
<freemangordon>
5.17-rc1 I guess
<freemangordon>
anyway, this is not important
<tmlind>
i need to also update my pending omapdrm fix, and then we need to make sure the vblank patch does not cause performance loss at least for xorg
<tmlind>
ah right v5.17-rc1 :) too many tags.
<tmlind>
.
<freemangordon>
tmlind: I think someone shall spend time on TE support in omapdrm
<freemangordon>
this will make vblank patch obsolete too
<freemangordon>
as it is a kind of hack IIUC
<tmlind>
afaik te is not available on droid4
<freemangordon>
sure it is
<tmlind>
where do you see it? there's no te gpio
<freemangordon>
I looked at android vendor code
<freemangordon>
yes, there is no gpio
<freemangordon>
but that does not mean there is no TE
<freemangordon>
sec
<tmlind>
note that the stock kernel has support for multiple displays where some may have te
<freemangordon>
yes, I know
<tmlind>
something would need to produce a te interrupt from the panel, right?
<freemangordon>
yes
<freemangordon>
and this is DSI controller ;)
<tmlind>
oh
<freemangordon>
gimme a minute to find TRM page for you
<tmlind>
yup if the dsi te interrupt works, no need for the vblank emulation
<freemangordon>
according to board_mapphone.c it works
<tmlind>
so for v5.17-rc1 based branch, i want to fix up "
<tmlind>
drm/omap: Fix shmem write-combined buffer handling" patch a bit, there's another cosmetic fix related to it
<tmlind>
let's leave out the vblank for now then
<freemangordon>
do we need that still? IIRC this was causing N900 to not boot
<tmlind>
hmm i think i fixed it for n900
<freemangordon>
hmm, ok
<freemangordon>
we'll see
<tmlind>
afaik droid4 won't work with the paging code without it
<tmlind>
needs to be verified again sounds like though :)
<freemangordon>
see "10.3.4.4.9.2 Tearing Effect"
<freemangordon>
"There are two types of TE triggers:..."
<freemangordon>
mapphones use DSI PHY TE trigger
<freemangordon>
but I guess panel has to be programmed correctly for this to work
<freemangordon>
I tried to fix support in omapdrm (to see that TE intr is generated), but it was not generated
<freemangordon>
but I think it was not my code at fault (I was basically setting couple of bits in DSI regs, the same way vendor kernel does it), but lack of some magic commands that panel driver issues in vendor kernel
<freemangordon>
but, I won;t have time to look at that soon
<tmlind>
ok cool, i'll take a look at that
<tmlind>
hmm we have something with DSI_CATCH_MISSING_TE for that
<freemangordon>
lemme see if I stashed the changes
<freemangordon>
yes I did :)
<tmlind>
maybe we don't have dsi_te0 pin muxed right..
<freemangordon>
we don;t need it at all
<freemangordon>
IIUC
<freemangordon>
this is needed only if you use te gpio, iiuc
<freemangordon>
obviously the want to track all GEM handles they use, but the do so by allocating array of size of biggest handle number!
<freemangordon>
how hard is to use lists, dammit
<freemangordon>
or even hash tables, if we are to track 1000s of BOs
<Wizzup>
heh
<Wizzup>
I'm going to look at the pine64 kernel stuff again now
<Wizzup>
I'll maybe just rename and see what happens
<freemangordon>
hmm, something wrong with 'y' symbol on my kbd?
<freemangordon>
y y y
<freemangordon>
looks fine :)
<freemangordon>
Wizzup: don;t really know what to do with the issues we have with omapdrm
<freemangordon>
one one hand I don;t want to waste any more time on that
<freemangordon>
on the other - it crashes
<freemangordon>
and I know why
<Wizzup>
is this the fragmentation problem?
<freemangordon>
yes
<freemangordon>
also, somehow we have issue on n900, that in theory we should not have
<freemangordon>
I don;t think scanout (so CMA) buffers are reallocated at all
<freemangordon>
so, why we hit that CMA error is not clear to me
<freemangordon>
Wizzup: a simple hack on d4 will solve the issue most-probably
<freemangordon>
like: never allocate buffers from DMM
<uvos>
i mean its any buffer right
<freemangordon>
yes
<uvos>
(gets allocated on dmm on current omapdrm)
<freemangordon>
*every
<uvos>
but dident on 5.11
<uvos>
so bisect maybe
<freemangordon>
besides rotated scanout
<uvos>
and complain to whomever did the commit
<freemangordon>
uvos: no need
<freemangordon>
this needs to be fixed IMO
<freemangordon>
but, the fix should be smart, like: allocate all scanout buffers from TILER
<uvos>
sure but im saying its a new problem introduced in between 5.11 and 5.15 indpendantly from sgx into omapdrm, aka mainline
<uvos>
so complaining to the author seams resonable
<freemangordon>
it is not that simple, as part of the solution in 5.11 are the so-called 'omapdrm' hacks
<uvos>
ok
<freemangordon>
so upstream code was broken
<uvos>
ok
<uvos>
i gues your quick fix is just reapplying the hack
<freemangordon>
also, I see a general issue in GBM BO stuff/DRM dumb buffers
<freemangordon>
we have various flags when creating GBO BOs (like GBM_BO_USE_SCANOUT etc)
<freemangordon>
however, there is no way those to be passed to kernel
<uvos>
ok
<freemangordon>
drm_mode_create_dumb has flags member
<freemangordon>
but: noone uses that
<uvos>
ok
<uvos>
so how about: reapply/reimplement old hack, complain about problem on omap ml, and drm ml, do something else, home someone fixes the problem by the time your done with "sonehing else", otherwise look at problem again.
<uvos>
s/home/hope
<freemangordon>
so, in order to fix dri3 on pvr, I will have to RE libdbm and replace DRM_IOCTL_MODE_CREATE_DUMB with omap_bo_create_xxx I wanted to get rid of
<freemangordon>
noone will fix it, as obviously noone uses that for anything sane besides us
<freemangordon>
if I complain to Tony, I can bet he will start talking about omapdrm not being general memory allocator etc
<freemangordon>
sorry, to Tomy
<freemangordon>
OTOH we are using blobs that (abuse)use omapdrm - there is a check if fd of drm device being passed is fd of omapdrm
<freemangordon>
-22 if not
<freemangordon>
-19 actually
<freemangordon>
"OS error code 19: No such device"
<freemangordon>
I mean: this is full with hacks all over the place :(
<uvos>
this should not be that suprising
<freemangordon>
I was hoping at least open parts to be looking better
<freemangordon>
but actually they are worse
<freemangordon>
I hate to tell it, but blobs/pvr driver follow specs way better than open parts
<freemangordon>
will exit rant mode soon, I promise :)
<sicelo>
:-)
<freemangordon>
ok, plan for tomorrow: hack omapdrm to *not* allocate DMM buffers, unless those are scanout
<freemangordon>
hack DDX to always allocate scanout buffers as TILER buffers
<freemangordon>
I hope this will fix it at least on d4
cockroach has joined #maemo-leste
<Wizzup>
freemangordon: understood
<Wizzup>
freemangordon: maybe we can get tomi involved somehow, since we seem to be one of the more sophisticated users that also actually use powervr
<Wizzup>
tmlind: did we send tomi a droid4, do you remember?
<freemangordon>
that would be great, at least for discussing on what would be accepted upstream and what not
<Wizzup>
freemangordon: I don't know how to do it, maybe we make a video of the current state and maybe link that on the ml or something
<freemangordon>
what do you mean by "current state"?
<Wizzup>
droid4 -devel with maemo
<freemangordon>
ok, but what to show there? the progress?
<freemangordon>
I don't understand the point, please elaborate
<Wizzup>
I just mean show off how well it works now, and maybe he will be interested in solving the existing problems
<freemangordon>
ah, ok
<Wizzup>
just to motivate or grab attention, I don't know :)
<freemangordon>
yeah, why not
<freemangordon>
will you do that? Your d4 is way more in "end user" state than mine
<Wizzup>
yeah, maybe we can just make one for the news update and include this
<freemangordon>
you do the PR stuff, I will do problems description in a follow-up letter
<freemangordon>
yeah, why not
<freemangordon>
having 5.15 i snews, no?
<Wizzup>
I was kind of waiting for this to hit -stable to do news post, but maybe we can just tout about it when it is in -devel too
<Wizzup>
freemangordon: yes, we will have news update soon
<freemangordon>
ok, lets see if I will be able to fix DMM issues tomorrow
<Wizzup>
ok, I hope to have a python or C telepathy client for irc or sms before I go to sleep
<Wizzup>
command line but still
<freemangordon>
and RE libdbm today
TonyStone has quit [Remote host closed the connection]
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #maemo-leste
<uvos>
implementing a sphone module for its chat/sms system is probubly less than a command line client from scratch
<uvos>
Wizzup: just saying :P
<uvos>
*less work
<Wizzup>
it's more about using tp api than creating a cli prog
<Wizzup>
ofc any cli thing I make is just to test
<uvos>
sure i know
tmlind has quit [Ping timeout: 252 seconds]
tmlind has joined #maemo-leste
TonyStone has joined #maemo-leste
TonyStone has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
TonyStone has joined #maemo-leste
jk_ has joined #maemo-leste
uvos has quit [Ping timeout: 240 seconds]
<jk_>
hello Leste's! :)
<jk_>
great work! really! I admire all the people involved behind the scenes in and for this free and ethical platform!
<freemangordon>
Wizzup: I think I have a patch for DMM fragmentation, unfortunately batter went flat and I am unable to charge it - as soon as h-d starts, device shuts down because of low battery despite being on fastcharger :(
<freemangordon>
jk_: :)
<jk_>
I have a Droid4 and it is looking pretty ripe! got leste on it arround may 2019
<Wizzup>
freemangordon: I can apply and test if you want, if you boot with cable plugged in I think you should get the charge-mode?
<Wizzup>
jk_: hi :)
<jk_>
it helped me go deeper in the command-line. I have learned so much!
<freemangordon>
Wizzup: charged through android, it told me 15%
<freemangordon>
yeah, not it booted
<Wizzup>
jk_: the next update will contain a lot more cool stuff :)
<freemangordon>
Wizzup: going to push, please make new kernel release in few minutes
<jk_>
Wizzup: that's great!
<jk_>
so, I have one little problem with my Droid4: using a USB-DAC. ometimes it works, but most of the time the device crashes when I plug it in
<Wizzup>
freemangordon: ok, will do
<Wizzup>
jk_: so this is usb host mode with a usb audio card, do I understand correctly?
<jk_>
yes
<jk_>
and the card is an ODAC or "objective DAC" an open hardware device
<jk_>
... creative commons license, I believe
<Wizzup>
I have not toyed around that much with usb host mode on the droid4 I have to admit, it is possible that our new 5.15 based kernel will work better
TonyStone has quit [Ping timeout: 240 seconds]
<Wizzup>
I think the best thing to do is test that when we push it out (real soon) and then if it still crashes see if you can find anything in /var/log/
<freemangordon>
Wizzup: pushed
<Wizzup>
freemangordon: I'll do tag and rebuild
<freemangordon>
thanks!
<freemangordon>
please test and report if it still crashes
<jk_>
Wizzup: ok, fair enough, I can wait for that :)
<freemangordon>
hmm, device turned off again :(
<Wizzup>
freemangordon: will do, it might take 1-2 days for me to report on that, although I can try some stress tests
<Wizzup>
freemangordon: there is code in mce now to shut down on low battery afaik, maybe you are hitting that
<jk_>
oh, yes... for completion: DAC = digital to analog converter
<Wizzup>
jk_: cool, what are you using it for btw?
<Wizzup>
yeah I know :)
<freemangordon>
yeah, seems this is what I am hitting
<freemangordon>
but, battery is @ 20 %
<Wizzup>
freemangordon: should not happen if you keep cable plugged in, right?
<freemangordon>
and device connected on charger
<freemangordon>
mhm
<Wizzup>
I don't think it should trigger then
<Wizzup>
uvos^^
<Wizzup>
freemangordon: are you sure you're hitting this? that should be noted in /var/log I think
<freemangordon>
hmm, android shows 5%
<Wizzup>
mce is based on voltage I think
<freemangordon>
well, cannot boot now
<Wizzup>
not upower reporting
<Wizzup>
new kernel is building
<freemangordon>
will let it charge for a while
<Wizzup>
btw, my plan for today/tomorrow is to at least get the pine kernel and ofono stuff done, and the tp test client
<Wizzup>
I really hope we can get enunez to help us :)
<jk_>
the DAC? for supreme quality music ^^ ... just a month ago i discovered the pianobar package which is a pandora-radio client. and I am a pandora subscriber... eventhough it is only available in the US and I am in Germany, I can Torify it and use my old account that I had in 2004 while in my hometown in Mexico
<Wizzup>
heh :D
<freemangordon>
sounds complicated :)
<jk_>
so, using the console to listen to online radio leaves the CPU and MEM pretty low, and that's the future!
<Wizzup>
how long can you do that on battery?
<freemangordon>
well, on leste we are already low on MEM and CPU, even with GUI running IMO
<jk_>
battery? well, long enough, one hour or two. I have not exhausted it yet... could do a full test once the DAC works ^^
<Wizzup>
I think probably usb host uses quite some power
<jk_>
freemangordon: yeah! that's amazing!
<Wizzup>
I can listen to music on leste for ~13 hours or so on a full battery with mpv
<freemangordon>
5.15?
<jk_>
yeah, 5V... some Watts... but there are hubs with charging ports!
<Wizzup>
freemangordon: yes
<Wizzup>
jk_: yes, I wonder if that works
<jk_>
Wizzup: damn! that's a good quota!
<Wizzup>
yeah wondering if we can get that up further if we make the audio buffer larger (if at all possible) so that device can sleep until the buffer is played back
<Wizzup>
but no idea how that actually works :p
<jk_>
Wizzup: it should hehe, there are also some special OTG cables with power input and USB host... i think some resistor is builtin to deal with the frequencies or something like that. I saw a DIY video tutorial once, but I went for a ready one from ebay