18:28 <DavidHeidelberg> Someone just reminded me, that since I dumped 5.9_rc2-next-grate to pmOS, it's still there :D so, now question is comming -> if you would want kernel for end-users, which should I use? 1. just take latest -next-grate and test it, or is there something like LTS or mainline with -grate patches?

18:29 <DavidHeidelberg> generally I think since 5.9_rc2 is without complaints, some LTS would make sense, so distribution maintainers can just linux-5.xx.y+1 easily without requiring some extra testing or cooperation from me or #tegra

19:32 <DavidHeidelberg> digetx btw. I tried integrate asus-grouper pmOS kconfig into CI, but sadly warning (so error) appears, any idea: https://github.com/okias/linux/runs/3204916202?check_suite_focus=true#step:8:3225 ?

19:34 <DavidHeidelberg> https://patchwork.kernel.org/project/linux-arm-kernel/patch/7301172.5fH67MHlU9@wuerfel/ implies it's harmful, but it's from Feb 2016

19:39 <digetx> there is CONFIG_FRAME_WARN which can silence that warning

19:44 <digetx> the mainline 5.13+ should work okay on nexus, but it will miss out the WIP power management improvements of next-grate

19:45 <DavidHeidelberg> so let's say, for now I'll bump it to another -next-grate, is it currently good time?

19:47 <digetx> I'm finding all kinds of new problems all the time in -next, so there is a trade off

19:47 <DavidHeidelberg> digetx btw. shouldn't FRAME_WARN should stay 1024 for arm and this just be exceptioned? I plan to send mail to author of the patch to send it again, if it makes sense

19:48 <digetx> I don't have that warning

19:48 <digetx> on next

19:49 <DavidHeidelberg> yeah, I see from CI, it's due to different defconfig it seems to be

19:49 <digetx> maybe it was fixed already, but not backported in older kernels

19:49 <DavidHeidelberg> nope, that's from current grate master

19:49 <digetx> ah

19:49 <DavidHeidelberg> https://github.com/okias/linux/runs/3204916202?check_suite_focus=true#step:8:3225

19:50 <DavidHeidelberg> this is just CI I'm preparing, which compiles also asus-grouper kernel config

19:50 <digetx> you may try to ask about the fix then

19:51 <digetx> FRAME_WARN should be 1024 for arm

20:02 <DavidHeidelberg> digetx with his proposal no warnings, compiled, now I'll give a shot in pmaports. Anyway, also I'm thinking about adding CI builds with Thumb2

20:03 <DavidHeidelberg> would be interesting for Tegra2 devices with low memory

20:03 <DavidHeidelberg> and also I guess thumb2 is largely untested

20:04 <digetx> I'm using thumb2 since nobody else testing it

20:05 <DavidHeidelberg> digetx did u found some issues or noticed some performance gains?

20:05 <DavidHeidelberg> also kernel for grouper would be good adept for thumb2, since it needs to be under 3.x MB boundary

20:07 <digetx> ftrace doesn't with thumb2, which is unimportant

20:07 <DavidHeidelberg> "Is being held until the list moderator can review it for approval.".. linux-arm-kernel ML is not friendly to me

20:08 <digetx> thumb helps the kernel size, not sure about performance

20:11 <DavidHeidelberg> I assume performance for kernel should suffer only 1-2% (at least looking at some presentation).

20:12 <DavidHeidelberg> What I perceived that regular software have sometimes performance tuning for arm without thumb2, but with thumb2 enabled these optimizations gets disabled, which can hurt

20:34 <DavidHeidelberg> digetx thumb2 version seems to be circa 300K bigger, not sure what to think ;-) https://github.com/okias/linux/releases

20:37 <DavidHeidelberg> and I guess I know why. xz compression algoritm seems to be unable to handle it so well

20:38 <DavidHeidelberg> decompressed vmlinuz with thumb 10,539,992

20:38 <DavidHeidelberg> without thumb: 12,359,772

20:38 <digetx> https://github.com/grate-driver/linux/actions/runs/1083391069

20:40 <DavidHeidelberg> dmn, it seems that changelog is too big (which gets generated from commits)

20:48 <DavidHeidelberg> digetx I think it's solvable with this, not yet merged, PR https://github.com/marvinpinto/actions/pull/72

20:51 <DavidHeidelberg> 3. thing -> would it make sense to convert grouper pmOS config into defconfig, since it has to be standalone from default tegra one?

20:51 <DavidHeidelberg> s/1./3./

20:59 <DavidHeidelberg> https://github.com/okias/linux/runs/3205372530?check_suite_focus=true 2x2x2 combinations, clang x gcc, arm x thumb2, tegra_defconfig x asus-grouper

20:59 <DavidHeidelberg> all good

21:09 <digetx> we can add min size defconfig, but it doesn't need to be specific to grouper