gouchi has quit [Remote host closed the connection]
gouchi has joined #tegra
digetx has quit [Ping timeout: 258 seconds]
digetx has joined #tegra
<DavidHeidelberg>
digetx Hello, what would you name in points for -grate-next 5.9 -> 5.14-rc3 changelog? also is there some defconfig options which should be enabled for grouper/tilapia?
<digetx>
hi, what changelog?
<DavidHeidelberg>
digetx I mean, what can be visible for Nexus users after moving from 5.9 to 5.14?
<DavidHeidelberg>
better power management (I haven't followed much tegra development recently)
<DavidHeidelberg>
?
<digetx>
power management only in grate-next for now
<digetx>
I don't remember what was in 5.9, perhaps there is nothing user-visible, 5.14 mainline now has drivers support that was missing in original 5.9
<digetx>
the changelog is "everything is in upstream now"
<digetx>
this also means that the most recent upstream userspace may also be required for a full featured support, like alsa ucm for example
<DavidHeidelberg>
Alpine is rolling, so I'm not worried about that :) that's great, so generally 5.14 except PM should be interreplaceble with -grate ?
<DavidHeidelberg>
so tegra_partititions got upstream already?
<digetx>
tegra partition shouldn't be needed for grouper
<DavidHeidelberg>
cool
<digetx>
5.14 should work okay
<DavidHeidelberg>
PM work will likely get to 5.15 or 5.16?
<digetx>
doesn't depend on me, the review is going slow
<digetx>
5.16+
<DavidHeidelberg>
kk :) hopefully it gets in before LTS release, I'd like to keep pmOS with LTS, to ease up maintanance
gouchi has quit [Remote host closed the connection]
<DavidHeidelberg>
ok, booted, seems to be running just fine
<DavidHeidelberg>
5.14.0-rc3-next-20210729, anything needed in defconfig for OTG (sadly cannot test, I don't have reduction)
<digetx>
nothing needed
<DavidHeidelberg>
good :)
<jenneron[m]>
David Heidelberg: maybe you can adjust linux-postamarketos-grate config for grouper? iirc zImage is less than 5 MiB there
<jenneron[m]>
then your MR about moving to community may go
<DavidHeidelberg>
jenneron can it go under like 3.3 M ? :P
<DavidHeidelberg>
it would make me a happy man if I could do that. It's reason why grouper has still standalone kernel
<jenneron[m]>
lol
<jenneron[m]>
i think we can move all device-specific things to modules, except ones which are needed to boot into initramfs
<jenneron[m]>
then we can add deviceinfo_modules_initfs for all devices which use the package to support battery, touchscreen and panel in initramfs
<jenneron[m]>
iirc there is also some config for modules compression
<DavidHeidelberg>
yup, that's kinda new
<DavidHeidelberg>
I'm considering to test thumb2 in future too
<DavidHeidelberg>
currently my effort was to test new kernel and push it, since I felt guilty that one guy on twitter tagged me that he use the 5.9 kernel with Ubuntu... and... our goal is to supply up-to-date kernels, not to match Android development cycle :D
<DavidHeidelberg>
ofc, 5.9 kernel worked so well, it seems legendary now :D
<jenneron[m]>
so grouper config is 3.3 MiB now?
<jenneron[m]>
zImage*
<jenneron[m]>
can you do `make savedefconfig` in your kernel dir and send it?
<DavidHeidelberg>
everything non-critical is module
<DavidHeidelberg>
which in general is stupid on embedded device, when you KNOW you'll need it (not HW variant dependent stuff ofc)
<DavidHeidelberg>
so boot is slightly slower, but.. well..
<DavidHeidelberg>
it works :)
<jenneron[m]>
well, it's stupid for one device
<jenneron[m]>
when we share one kernel package between a dozen, that's no needed to have built-in modules which are needed for 1 of them
<DavidHeidelberg>
from my POV it would make sense to have one source, one recepie and diff for each device, where you build optimized kernel for each device
<jenneron[m]>
it is more difficult to maintain than one package for all
<DavidHeidelberg>
having generic zImage and just pass DTS is worthwhile for computers or tablets with space to waste
<DavidHeidelberg>
yeah
<DavidHeidelberg>
but at some point, when grouper reach parity with mainline and gets to closest LTS release, it will be just keeping with 5.xx.y+1, so maintanance is just bumping version and sha512, so no pain
<DavidHeidelberg>
also pushing many modules for different devices on rootfs which is like 7G (for 8G variants) is overkill
<DavidHeidelberg>
jenneron do u have some tegra devices on F2FS?
<jenneron[m]>
no
<jenneron[m]>
but it may be reasonable for emmc
<DavidHeidelberg>
just noticed that I have still F2FS disable since my experiments in 5.9 (which lead to crashes, but should be fixed these days)
<jenneron[m]>
David Heidelberg: btw there is a fix for osk-sdl intruduced today in pmaports
<jenneron[m]>
which makes it usable on T30
<jenneron[m]>
it was painfully slow before
<DavidHeidelberg>
cool :)
<DavidHeidelberg>
jenneron I see you have F2FS compiled in, I recommend switch your rootfs(s) as fast you can, you can prolong emmc life a lot :)
<jenneron[m]>
that won't help tf701t with broken eMMC in kernel xD
<DavidHeidelberg>
well... :P no
<jenneron[m]>
surface rt i test with usb booting, just tested ondev installer with "console" environment several times
<jenneron[m]>
i test surface rt*
<DavidHeidelberg>
digetx one thing looking at dmesg -> I assume this is fine: [ 64.222954] rt5640 0-001c: Failed to reguest IRQ 0: -22
<digetx>
yes
<DavidHeidelberg>
digetx if are u still awake, do you also have in logs this message brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available ?