TonyStone has quit [Remote host closed the connection]
<Wizzup>
uvos__: re: more corruption could also be that you have a custom theme and/or backgrounds on your other devices
TonyStone has joined #maemo-leste
Pali has quit [Ping timeout: 268 seconds]
uvos__ has quit [Ping timeout: 256 seconds]
cockroach has quit [Quit: leaving]
sunshavi_ has quit [Remote host closed the connection]
macros__ has joined #maemo-leste
macros_ has quit [Ping timeout: 268 seconds]
joerg has quit [Ping timeout: 256 seconds]
Daaanct12 is now known as Danct12
joerg has joined #maemo-leste
<freemangordon>
Wizzup: one more thing while we are at it - I think it makes sense to not set zswap on n900 but use dedicated swap partition on eMMC
<freemangordon>
also, using 16bpp will greatly reduce memory usage
inky_ has joined #maemo-leste
DPA- has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
DPA has joined #maemo-leste
inky_ has quit [Read error: Connection reset by peer]
inky has joined #maemo-leste
inky_ has joined #maemo-leste
ikmaak2 is now known as ikmaak
inky has quit [Ping timeout: 256 seconds]
inky_ has quit [Read error: Connection reset by peer]
inky_ has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
inky_ has quit [Read error: Connection reset by peer]
xmn has quit [Ping timeout: 260 seconds]
<Wizzup>
freemangordon: yeah I am still not convinced about zswap being a bad idea and swapping to slow and irreplaceable disk instead
bencoh has joined #maemo-leste
bencoh has quit [Changing host]
<parazyd>
Yeah swapping on such storage is bound to degrade lifetime
dingen has joined #maemo-leste
dingen is now known as dreamer
alex1216 has joined #maemo-leste
Pali has joined #maemo-leste
sunshavi has joined #maemo-leste
alex1216 has quit [Ping timeout: 240 seconds]
inky_ has joined #maemo-leste
uvos__ has joined #maemo-leste
<Wizzup>
parazyd: hm it looks like /etc/kernel/postinst.d runs before the postinst of our kernel image package
<Wizzup>
that can't be right?
<uvos__>
parazyd: irc.txt is broken
<Wizzup>
parazyd: hmmmm I guess our modifications to builddeb actually make it run our stuff before run-parts
<Wizzup>
that's wrong
lel has joined #maemo-leste
<Wizzup>
I fixed builddeb
<uvos__>
freemangordon: is it really smart to swap on emmc on a device thats 10+ years old? its probubly getting up there on writes allready
<Wizzup>
well it depends right
<Wizzup>
if we want 0.75GB of swap we will need to do that
<Wizzup>
(which is what fremantle has)
<Wizzup>
we could swap to sd card as well but it is kinda slow
<Wizzup>
otoh I think a bit of zswap really isn't a bad idea
<Wizzup>
of course not too much, and maybe our ratio is off
<uvos__>
if the 100mhz clock hack works on omap3/n900 then modern sdcards way outprerform mmc
<Wizzup>
you tried this mostly on d4 though right?
<Wizzup>
also iirc n900 bus width is small
<uvos__>
exclusively yeah
<uvos__>
its 4bit like d4
<uvos__>
emmc bus with is 8
<uvos__>
on both
<uvos__>
doubleing the bus clock levels the field
<Wizzup>
ok
<bencoh>
the "hack" is basically allowing SDR104 even though it shouldn't be supported?
<uvos__>
not really
<uvos__>
so we can do in spec sdr50 with 5v bus
<uvos__>
omap4 can also do sdr100 @5v and ddr50 @5v and thats supported by some mmc chips
<bencoh>
5V or 3.3V?
<uvos__>
but sdcard spec for uhs1 is 50mhz @5v sdr or 50mhz @1.8 ddr or 100mhz @1.8v sdr
<uvos__>
we cant do 1.8v at all
<uvos__>
s/5v/3.3v
<uvos__>
see sdcard uhs1 spec page 3
<freemangordon>
Wizzup: re zswap, as I told you, I played enough with compcache (which is the same) back then, and I can tell you that it only makes things worse
<freemangordon>
slow CPU on 256 MiB RAM zswap is a recipe for disaster
<freemangordon>
even if you tell it to be 64MiB only
<freemangordon>
so, we either have a dedicated swap partition on uSD (which will be slow as hell) or we use swap partition which is already there
<freemangordon>
not much we can do about eMMC wearing
<Wizzup>
I think we will give users the option
<Wizzup>
We do zswap every where at the moment and it hasn't caused many problems really
<bencoh>
including n900?
<Wizzup>
yes
<Wizzup>
btw, once latest droid4-linux is done I think n900 on experimental should apt-get upgrade to newer 5.15 kernel
<Wizzup>
including postinst hook
<Wizzup>
I still got a X crash on it after opening ~5 terminals though
<Wizzup>
bencoh: but we might want to tweak the ratio for some low power devices perhaps
<freemangordon>
Wizzup: please disable that on n900
<Wizzup>
freemangordon: will it help with the x crash?
<freemangordon>
do you want me to give you the link to TMO thread?
<freemangordon>
bencoh: no, my question was not how to set it, but how to choose the size itself
<bencoh>
ah
<freemangordon>
like, do we prefer 16MiB or 64MiB
<freemangordon>
Wizzup: I don;t understand why it behaves liek that on your device
<bencoh>
well, simply count how many frames we need, round frame size to silly-aligned-size (I don't know what it is aligned to on n900), and it should give us the required size
<bencoh>
that's how I do it $here
<Wizzup>
freemangordon: maybe try with repo kernel
<Wizzup>
freemangordon: it's still building fwiw but the only diff is the postinst script swap
<Wizzup>
(swapping of what runs when)
<freemangordon>
Wizzup: ok
<Wizzup>
freemangordon: probably easier to just fetch the branch and build yourself
<Wizzup>
in any case when this works ok/stable I will push all experimental stuff to -devel for n900 and then we can empty experimental
<freemangordon>
:nod:
<Wizzup>
one thing I kind of want but won't for now is to have drm built in
<Wizzup>
last time I tried that gave trouble, but it would be real nice to have fast tty output
<mighty17[m]>
tried running xfce with openpvrsgx and freemangordon's mesa, and it fails even on sw rendering https://paste.debian.net/1225677/ (i didnt set MESA_LOADER_DRIVER_OVERRIDE=pvr coz idk how its done in x)
<freemangordon>
mighty17[m]: you should provide correct kmsdev to modesetting
<mighty17[m]>
as in? i havent touched x at all
<uvos__>
xorg.conf
<Wizzup>
freemangordon: seems ok now, also with zswap or, and with normal swap on
<Wizzup>
so we can rule out any form of swap being a problem
<uvos__>
also MESA_LOADER_DRIVER_OVERRIDE dosent have anything to do with the window manager
<freemangordon>
Wizzup: yeah, but I still kind of think zswap should be disabled
<uvos__>
s/window manager/windowing system
<mighty17[m]>
uvos__: well but in wayland i had tinydm which'd set env vars for me
<freemangordon>
Wizzup: also, I think 24 MiB or even 16MiB of CMA should suffice
<mighty17[m]>
uvos__: cant find it :(
<Wizzup>
up to you , I am fine with whatever doesn't cause crashes
<uvos__>
mighty17[m]: the xdg-session manager also has nothing to do with wayland vs x
<uvos__>
they just start a xdg-session that starts some windowing system
<freemangordon>
Wizzup: maybe try with 16 MiB
<freemangordon>
or...
<Wizzup>
freemangordon: I suggest we potentially postpone finding the exact number
<mighty17[m]>
uvos__: right soo im confused aboout modsetting part
<Wizzup>
I'm really hoping that I can start doing some non-kernel stuff again soon
<freemangordon>
ok, make it 24 then
<freemangordon>
not 32
<Wizzup>
there are open issues but those are now mostly regarding idle/ret/off mode
<Wizzup>
and I also have to do some work-work today :p
<freemangordon>
ok :)
<uvos__>
mighty17[m]: man modesetting
<Wizzup>
freemangordon: this is great though
<Wizzup>
freemangordon: I am not sure if it is at same perf as 5.1 with other ddk and other clutter
<Wizzup>
but this is good
<freemangordon>
it is not
<freemangordon>
it is slightly slower
<Wizzup>
yeah it feels a bit more stuttery
<Wizzup>
but fine for now
<freemangordon>
but, this is because of we wait in DDX for gpu rendering to complete before requesting flip
<uvos__>
freemangordon: interesting side note
<freemangordon>
instead of omapdrm waiting for write fence to be signalled
<mighty17[m]>
uvos__: `man: No entry for modesetting in the manual.` :(
<freemangordon>
mighty17[m]: sec to boot my d4
<freemangordon>
uvos__: hmm?
<uvos__>
mighty17[m]: freemangordon: since you worked around the corruption (looks like missing tiles) in omap ddx, when the d3/d4
<uvos__>
upps
<uvos__>
freemangordon: since you worked around the corruption (looks like missing tiles) in omap ddx, it dosent show up anymore but when the d3/d4 hangs (d3 dose it way more often) it displays a frame that has the corruption again as its last frame
<uvos__>
we were keeping sgx and the rest of the kernel seperate for a reason...
<freemangordon>
hmm?
<Wizzup>
uvos__: this is my wip branch, it is not meant to be the main branch for all our stuff, but if you're worried about a rebase I am happy to cherry pick 15 commits
<uvos__>
ok
<Wizzup>
and no I didn't rename the repo yet
<Wizzup>
we can do that if we want
<freemangordon>
Wizzup: if you're going to do that (cherry-pick), please LMK, or simply make sure you don;t cherry-pick old versions of my omapdrm/pvr patches which a re reverted later-on
<uvos__>
so if you need to bisect some problem you dont want sgx in the tree, really. also keeping the sgx seperate makes sense for people who want a untainted kernel
<mighty17[m]>
so its mainline? (i dont think patches for d4/n900 specific help me on espresso)
<uvos__>
i liked that the sgx stuf was seperate
<uvos__>
and was merged at compile time
<uvos__>
mighty17[m]: the d4 paches do help you on espresso
<Wizzup>
uvos__: it was never merged at compile time?
<mighty17[m]>
i dont seem to understand the diff in kernels (openpvrsgx and leste-omap)
<bencoh>
uvos__: basically you're saying you prefer it as a set of patches?
<uvos__>
bencoh: essentally
<bencoh>
I'd rather have a branch
<uvos__>
or a branch but based on mainline
<uvos__>
and then leste patches in a different branch on mainline
<Wizzup>
freemangordon: btw so maybe we do not need compaction after all
<Wizzup>
since I had old ddx
<freemangordon>
Wizzup: yes, we have it :)
<freemangordon>
*need
<Wizzup>
ok
<uvos__>
do we need hugepages at all?
<uvos__>
if your worryed about fragmentation
<uvos__>
w/o compation
<uvos__>
*compaction
<freemangordon>
how will CMA work without that?
<uvos__>
idk how cma works so no idea
<uvos__>
thats why i ask
<freemangordon>
I think CMA will not work without it
<freemangordon>
someone shall do page migration when contiguous buffer is needed
<uvos__>
not having hugepages dosent prevent in kernel users allocating contiguous buffers
<uvos__>
afaik
<freemangordon>
we are not talking about huge pages, but compaction
<uvos__>
compaction was added for hugepages
<freemangordon>
once memory gets fragmented...
<freemangordon>
I think the same thing is used for CMA
<freemangordon>
but might be wrong
<freemangordon>
Wizzup: maybe it worths a try
<uvos__>
well the compatction stuff was added for hugepages since ofc having those causes lots of fragmetnation having only 4kb pages dosent
<freemangordon>
uvos__: ok, seems we lack knowledge, so Wizzup can try to disable compaction now he uses the correct DDX and see
<Wizzup>
I mean I am fine keeping it on with the timeout nerfed
<Wizzup>
just wanted to mention it
<uvos__>
yeah sure
<uvos__>
real fix is not having the timeout
<freemangordon>
Wizzup: sure, but if it is not needed, then it will mean less code and one patch less to carry
<freemangordon>
Wizzup: I can test too
<freemangordon>
but not sure how valid my test will be
<freemangordon>
Wizzup: btw, do I still need droid4 component on n900?
<bencoh>
basically compaction shouldn't run in idle
<bencoh>
and it shouldn't prevent the scheduler from entering idle either
<Wizzup>
freemangordon: I need to triple check all components, so keep it for now
<freemangordon>
ok
<freemangordon>
ugh: E: Unable to locate package maemo-kernel-config-n900
<freemangordon>
is that in experimental?
<uvos__>
yeah the 500ms timer is clearly silly, i mean whats the point of checking fragmentation potentaly hours since the device was last awake for anything. if nothing runs nothing can cause fragmentation
<Wizzup>
uvos__: regarding setup, which do we merge on top of which
<Wizzup>
uvos__: I guess what you suggest can work if tmlind carries all our non pvr patches
<Wizzup>
but not all of them are ready yet
<uvos__>
not sure why we need tmlind
<Wizzup>
well we were just based on top of his pending branches before
<uvos__>
well we can have an intermeidate branch
<uvos__>
thats his pending + our non pvr patches
<uvos__>
or tmlind can accept maintinaice of essentally linux-omap for leste
<uvos__>
he kinda dose allready
<uvos__>
tmlind: ^^^
<Wizzup>
uvos__: I think we/I need to do a bit of work and suggest which ones to carry
<Wizzup>
some of mine are just reverts for things that broke that we still need proper fixes for
<uvos__>
i gues a midway house here
<uvos__>
is we have linux-omap for leste with everything sgx+our patches+hacks+whatever
<uvos__>
and we try and "upstream" our patches to at least tmlinds brach soon
<uvos__>
and then we rebase the linux-omap leste branch on timlind with eatch release as before
<uvos__>
idk really what is best here
<Wizzup>
well I did try to upstream whatever fixes I had, I just ran out of time and energy for others
<Wizzup>
we'll have to revisit them in the future anyway
<Wizzup>
bbiab
<bencoh>
freemangordon: iiuic CMA should only use pre-allocated buffers
<bencoh>
so compaction (or lack thereof) shouldn't affect it
<bencoh>
basically you can even specify the CMA segment at boot (cma=42M@0x12120000)
huckg has joined #maemo-leste
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 256 seconds]
inky has quit [Ping timeout: 256 seconds]
inky has joined #maemo-leste
<tmlind>
Wizzup, uvos: it's best to try to mainline what we can, then set up topic branches that can be merged together for m-l kernel. i'd rather not start piling up patches, best to have uvos deal with his own patches, freemangordon deal with his patches etc
<tmlind>
then just merge those topic branches together :)
<Wizzup>
agreed
inky has quit [Ping timeout: 256 seconds]
<uvos__>
Wizzup: tmlind: looks like the touchscreen buttons are connected to KLC led cpcap channel
<uvos__>
and is probubly the same on xt86x
<uvos__>
*Wizzup: tmlind: looks like the touchscreen buttons are connected to KLC led cpcap channel on xt875
<tmlind>
uvos: hmm is klc keyboard light controller or something like that?
<uvos__>
yeah
<uvos__>
but its unused on d4
<tmlind>
ah
<uvos__>
with the keyboard being on the other led chip instead
<tmlind>
so does the xt875 firmware control the klc led then?
<uvos__>
its set on on reset
<uvos__>
other than that no i think
<tmlind>
ah ok, so linux could control it
<uvos__>
yeah
<tmlind>
nice
<uvos__>
for some reason
<uvos__>
in the current leste tree
<uvos__>
the sgx driver gets rebuilt on every build of modules
<tmlind>
yeah that sucks.. it's because we can't yet build all the socs into a single module :(
<tmlind>
uvos: so that's the CPCAP_REG_KLC then?
<uvos__>
yeah
<tmlind>
ok
<uvos__>
i have a patch incomeing
<tmlind>
:)
<uvos__>
also needs support added to the cpcap led driver for that channel
<tmlind>
ok
<Wizzup>
uvos__: let's coordinate on your various patches so we can get them in omap-linux
<uvos__>
ok
<tmlind>
when v5.15 is out, i suggest we all set up minimal personal topic branches, then attempt to merge them to m-l kernel
<tmlind>
i mean v5.16
<tmlind>
one or more topic branches per developer
<tmlind>
i think these branches already exist, we just need to merge them into the m-l kernel git tree
<Wizzup>
well yeah, but for m-l purposes we also want a stable branch, maybe 5.15 based now
<tmlind>
yeah, not sure if we want to redo the 5.15 branch though
<Wizzup>
well I am going to clean up my 5.15 based one, but it's based on your rc2
<tmlind>
most of these topic branches could be based on v5.15 at this point for sure
<Wizzup>
yeah mostly meant that having a pvr one based on 5.15.y would be nice, but I imagine it might even just rebase without conflicts
<tmlind>
yeah it should
<tmlind>
we need some kind of txt list of topic branches to merge in :)
inky has joined #maemo-leste
uvos__ is now known as uvos
pere has quit [Ping timeout: 252 seconds]
alex1216 has quit [Ping timeout: 256 seconds]
<freemangordon>
Wizzup: there is already 5.16-rc pvr repo
<freemangordon>
my patches should be already there
<freemangordon>
also, omapdrm patch is in rc as well
pere has joined #maemo-leste
<freemangordon>
so I think it makes sense to go for that
<freemangordon>
as next step ofc
mepy_ has joined #maemo-leste
<freemangordon>
hmm, it is in drm-next, maybe it will be in 5.17-rc
mepy has quit [Ping timeout: 245 seconds]
<freemangordon>
it is in linux-next, no idea what that means in terms of version
<Wizzup>
freemangordon: I'd like something stable for our users too
<uvos>
tmlind: hmm static mfd_cell dosent seam a good fit for cpcap
<uvos>
tmlind: since cpcap contains lots of devices that are often unused
R0b0t1`` has quit [Ping timeout: 240 seconds]
R0b0t1`` has joined #maemo-leste
Oksanaa has joined #maemo-leste
<uvos>
Wizzup: so the ts-buttons on d3 are also connected to cpcap klc
<uvos>
Wizzup: also the alt key light is on bledc
<uvos>
Wizzup: and shift key light is on cledc
<uvos>
neat that d2 has extra keyboard staus lights
LjL has quit [Quit: Scappò via con la paura di arrugginire. Il giornale di ieri lo dà morto arrugginito. I becchini ne raccolgono spesso fra la gente che si lascia piovere addosso.]
LjL has joined #maemo-leste
<uvos>
Wizzup: unfortinatly the backlight isent on cpcaps pannel backlight channel, nor any of the other cpcap channels
<uvos>
(d3)
<Wizzup>
uvos: thanks for investigating :)
<Wizzup>
huckg: did you manage with the bionic?
<huckg>
Thanks for asking, I was just getting some of the pieces together. The sparks will fly later tonight.
<Wizzup>
:)
<uvos>
Wizzup: tmlind: little question here, how do you get from the gpio numbers in userspace to the gpio banks in dts
<uvos>
i mean i know form expiramentation that <&gpio6 12> is 172
<uvos>
by way of 5 banks of 32bit + 12
<uvos>
but where is this defined?
huckg has quit [Quit: Client closed]
<Wizzup>
hm... I'm trying to remember how I figured this out last time
huckg has joined #maemo-leste
<Wizzup>
it might be in the logs, iirc you helped me with that
<uvos>
i probubly told you the (bank-1)*32+dts_number rule
<huckg>
It appears that I will have to do a crash course in qemu and bridging.
<uvos>
but i just found this rule by expieramenting with the interface and what changes :P
<Wizzup>
huckg: hm, bridging what? we probably need to document things if you run into problems
<uvos>
you have to brige the adb usb if into quemu
<uvos>
to root moto andorid 4.1
<huckg>
I have already rooted and installed safestrap and lineage 14.1, do I need to do these steps?
<uvos>
yes
<uvos>
do you have linageos on the stock slot or a sdcard slot?
<huckg>
not on stock slot
<uvos>
ok
<uvos>
the stock slot os need to be rooted
<huckg>
got it
<uvos>
also you will lose safestrap
<uvos>
btw
<uvos>
you atm cant boot android
<huckg>
ok, the bionic is just a toy for me now, not relying on it for anything important.