ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev>
no u
<steev>
but also, thanks for the reminder, that bit bamse and i while testing the next stuff
<steev>
robclark: does it have to be =y or can it be m?
<robclark>
I think it can be =m if you don't need display to probe before you have modules (or if you have modules in initrd).. I'm using =y because that is the easiest thing on a chromebook
<robclark>
it can be whatever PANEL_SIMPLE was before
<steev>
fair, we had that as =m in the aarch64-laptops distro_defconfig
<robclark>
ok, then =m should be fine
<steev>
asjdfl;asjkdf;laksjdf
<steev>
this friggin bluescreen
<robclark>
it's just to give you that familiar windows experience :-P
<steev>
i know but i'm trying to test thara's patches for cpufreq - it LOOKS like we get 2.96GHz finally :D
<steev>
just that the past 5 boots now i've gotten the blue screen
<steev>
not a HUGE issue because i can just close the display and then open after it suspends and it's "fine" minus the spam of the dmesg
<steev>
just frustrating to run into so many boots in a row
<steev>
also frustrating because ssh in and running reboot doesn't always properly disconnect before shutting down so the local terminal is in a hung state
<steev>
blargh
<steev>
as soon as i sent the email.... it worked the next boot
<steev>
bamse: is something wrong with patchwork? does it only get patches if it's not cc? i'm not seeing lumag's clk patch
<steev>
i also had to go and get thara's patches manually too
<bamse>
steev: odd, i've not had any problems recently :/
<steev>
hm, i see it in the web interface
<steev>
well, i see lumag's in the web interface, but not thara's
<macc24>
robclark: that config option is needed for pretty much all other chromebooks too... except krane
<macc24>
and couple others
<macc24>
currently i'm re-doing emmc installation in cadmium... would probably need to re-do it again though
* macc24
shoves veyron aside
<macc24>
all cadmium devices now *should* bootup on 5.16 kernel
<macc24>
basically i'm going to shove entire cadmium everything into cadmium image to build cadmium onto emmc itself xDD
<macc24>
cadmium recursion
iivanov has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
<robclark>
macc24: oh, nice.. I think homestar was the one that we were a bit late on getting dts upstream.. I think patches were posted before it started shipping but only land in v5.16
<robclark>
oh, and I guess he is using v5.16
<macc24>
robclark: 5.16-rc1 is quickest kernel release to reach cadmium
<macc24>
:D
<robclark>
:-P
<macc24>
either i became quite good at carrying patches through kernel versions, or there was less stuff happening
<robclark>
at least on the trogdor/strongbad side of things, we are trying to make sure there aren't many patches that need to be carried ;-)
<macc24>
yea
<macc24>
there are no trogdor specific patches in cadmium arm64 kernel