nighty-_ has quit [Quit: Disappears in a puff of smoke]
naobsd has joined #linux-rockchip
Ueno_Otoko has quit [Ping timeout: 240 seconds]
Ueno_Otoko has joined #linux-rockchip
masked_ has joined #linux-rockchip
philhug has joined #linux-rockchip
Danukeru has quit [Ping timeout: 246 seconds]
RayFlower has quit [Ping timeout: 246 seconds]
philhug_ has quit [Ping timeout: 246 seconds]
masked has quit [Ping timeout: 246 seconds]
rperier has quit [Ping timeout: 246 seconds]
tnn has quit [Ping timeout: 246 seconds]
tnn has joined #linux-rockchip
Danukeru has joined #linux-rockchip
rperier has joined #linux-rockchip
rory096 has joined #linux-rockchip
mrueg_ has joined #linux-rockchip
mrueg has quit [*.net *.split]
GekkePrutser has quit [*.net *.split]
GekkePrutser has joined #linux-rockchip
GekkePrutser has quit [Changing host]
GekkePrutser has joined #linux-rockchip
GekkePrutser is now known as Guest61611
ganbold has quit [Ping timeout: 255 seconds]
rory096 has quit [Read error: Connection reset by peer]
ganbold has joined #linux-rockchip
ssvb has quit [Ping timeout: 255 seconds]
<pulser>
mmind00: by the way, you were absolutely right about disabling vcc18_wl; it's "linked" to one of the regular voltage supplies, meaning it also turned off most other 1.8v stuff, so it won't wake from sleep
<pulser>
:)
ssvb has joined #linux-rockchip
ssvb has quit [Ping timeout: 240 seconds]
ssvb has joined #linux-rockchip
wadim_ has joined #linux-rockchip
naobsd has quit [Quit: naobsd]
AstralixNB has joined #linux-rockchip
ssvb has quit [Ping timeout: 240 seconds]
ssvb has joined #linux-rockchip
ssvb has quit [Quit: Leaving]
Ueno_Otoko has quit [Ping timeout: 244 seconds]
Ueno_Otoko has joined #linux-rockchip
* sjoerd
wonders if the spdif, hdmi interface actually works
vickycq has quit [Ping timeout: 250 seconds]
vickycq has joined #linux-rockchip
vickycq has quit [Ping timeout: 260 seconds]
vickycq has joined #linux-rockchip
<pulser>
mmind00: just spotted this in sleep from serial console (https://paste.debian.net/hidden/2ea01e7c/) - am up to date with the latest somewhat-stable here. The error is obviously not critical, but it just raised my interest as something that stood out - it slept and awoke fine that time too
<mmind00>
yeah, there is also always an rcu-warning on boot ... not sure what happens here, but it is somewhere in the arm-specific smp-code judging from the backtrace
<mmind00>
interestingly there are no real recent changes to it
<mmind00>
sjoerd: it is supposed to, but seems to need configuration
<pulser>
yes, I spotted the one on boot as well actually
<pulser>
having disabled the module in the kernel btw, I think that the wifi is indeed the cause - at least I cannot get it to fail to wake, when wifi module is unloaded
<pulser>
as a mainline kind of guy, you will be disgusted, but I will probably hack together a shell script to rmmod before sleep, and to insmod after a wake :P
<mmind00>
pulser: oh, I know that "solution" from my regular work ... so I won't get to disgusted
<mmind00>
:-D
<sjoerd>
mmind00: so i tried to get that running following the documentation, no go
<sjoerd>
checked inteh sdk source, all board seem to use i2s but there is some source for initializing the spdif hookup
<sjoerd>
also no go
<sjoerd>
even tried turning off the 8 channel spdif and use the 2 channel one just in case, no joy eitehr
<sjoerd>
Which all makes me wonder if anyone ever tested it :)
<sjoerd>
the chromeos driver and the one that rmk posted upstream but retracted both just use i2s
<sjoerd>
got that working now at least but needs some cleanup
<sjoerd>
and ofcourse it limits the rate to 96khz when uding multicodec (e.g. simultanious output over analog and hdmi
cnxsoft has quit [Quit: cnxsoft]
Ueno_Otoko has quit [Ping timeout: 246 seconds]
rory096 has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
wadim_ has quit [Quit: Leaving.]
cristian_c has joined #linux-rockchip
Guest61611 has quit []
Guest61611 has joined #linux-rockchip
Guest61611 is now known as GekkePrutser
AstralixNB has quit [Remote host closed the connection]
<pulser>
heh mmind00, I had an inkling you might be familiar with that technique, having seen how android is fixed for tight deadlines, but I didn't want to suggest your familiarity with it :P ;)
<pulser>
Note to self, to look at trying to enable the EC drivers on the minnie - I noticed the accelerometers etc weren't exposed, probably a kernel config or driver needing a quick port
<pulser>
once I get suspend haxxed, this will be a nicel ittle laptop to use
<mmind00>
pulser: hehe ... Minnie is quite cool ... especially that IPS display ... but when comparing personal usability, I still prefer the 13in variants :-)
GriefNorth has joined #linux-rockchip
naobsd has joined #linux-rockchip
<pulser>
Ah yes very true - my main laptop is 13, and the extra size is nice to have
<pulser>
But for portability, the 10" is definitely nice if you are travelling or just need to do a few quick things
<pulser>
The IPS is really nice though, just wish it was matte with touchscreen!
gb_master has joined #linux-rockchip
gb_master has quit [Client Quit]
rory096 has quit [Ping timeout: 265 seconds]
philhug has quit [Ping timeout: 240 seconds]
rory096 has joined #linux-rockchip
philhug has joined #linux-rockchip
jas-hacks has joined #linux-rockchip
naobsd has quit [Quit: naobsd]
vickycq has quit [Ping timeout: 264 seconds]
vickycq has joined #linux-rockchip
cristian_c has quit [Read error: No route to host]
cristian_c has joined #linux-rockchip
cristian_c has quit [Read error: Connection reset by peer]
<pulser>
mmind00: a question out of curiosity - my rmmod/modprobe script on suspend/resume is working nicely - I am wondering now if this logic stands to reason? That since I am fully re-initialising the driver (I assume all state/module data is gone on removal), it is worth me playing at disabling its power supply in kernel, since reloading module is doing a "full init"? :)
<pulser>
I am not worried about power usage, more just interested in learning these things, and seeing why my theories are wrong, as they then tell me more about how it works :)
<pulser>
blagh never mind; Wifi is on a shared power feed with other 1.8V things, it would freeze in suspend and not wake
sandy_ has joined #linux-rockchip
nashpa has quit [Ping timeout: 250 seconds]
nashpa has joined #linux-rockchip
GriefNorth has quit [Ping timeout: 250 seconds]
ssvb has joined #linux-rockchip
jas-hacks has left #linux-rockchip [#linux-rockchip]
<amstan>
pulser: don't you have the keyboard already working? i find it weird that you would have keyboard but not accelerometer
<amstan>
they're both the same driver
<amstan>
pulser: i think mmind00's tree should work with both
<pulser>
Everything core works like keyboard, yes
<pulser>
Accelerometer just doesn't seem to be exposed on sysfs
<pulser>
It may well be a config file issue - I need to have a look and ensure nothing obvious is turned off
<amstan>
pulser: CONFIG_CROS_EC_ACCEL ?
<amstan>
when they work, they show up in /sys/bus/iio/devices/iio:device0/in_accel_$axis_${base,lid}_raw
<pulser>
Yes, I was just doing find / | grep to look for it
<pulser>
But since it's not there in config that would definitely explain it!
<pulser>
amstan, as a general question, are the chrome OS configurations available? I was looking for them but couldn't find them in their tree (so many branches!), even on the ones that were named veyron
<amstan>
pulser: chromeos-3.14
<pulser>
I would rather have a good read over them, than annoy people with questions here :)
<amstan>
then chromeos/ folder
<amstan>
there's a set of scripts to make them
<amstan>
we like having them procedural in case we want to edit all chromebooks at the same time
<pulser>
I tried arch using the 3.14 kernel early on
<pulser>
I need to fire it back on and set it up as a second partition, and toggle the priority bit so I can compare things
<pulser>
As I am keen to try to see where needs attention on mainline - I'm looking at trying to bring across the VPU driver, or maybe the deep sleep support
<pulser>
So comparing the two will be useful :)
<amstan>
i have that setup, dual booting chromeos and arch by changing priorities
<amstan>
and i have space for more kernels too
<amstan>
just not enough time :)
<pulser>
Hehe yes exactly
<amstan>
i was considering making an arch package for mmind's tree at some point
<pulser>
I have it booting arch from the SD, and I have no idea what's on the emmc - either Chrome OS or debian
<pulser>
Yes indeed I had considered that, but I don't think he was hugely keen to get loads of users appearing :)
<amstan>
keep the package private
<pulser>
Yeah
<pulser>
I already have a build.sh, but not a package
<pulser>
My script just does the whole process and gives me a tar, and I just run a second install script on the Chromebook over ssh or uart
<amstan>
the chromeos bootloader even supports attempts at booting the partitions
<pulser>
Hmm, by any chance do you have cross compiling setup for arch packages? Just as you mentioned building the kernel as a package
<pulser>
Yeah, it's very well designed!
<pulser>
T flag iirc?
<amstan>
so you can mark a kernel as experimental, it'll try booting it, but if you didn't mark it successful it'll go to the other good kernel
<amstan>
i think it's success or tries
<amstan>
a combination of those
<pulser>
Yeah, I love that! So much easier than keeping a bootable SD
<amstan>
there's also a way to do tftp
<pulser>
Yeah - there's a success flag and a tries flag, which seem to be followed based on priority flag - if tries is 0, it stops
<amstan>
with ctrl + n
<pulser>
Oh interesting!
<pulser>
What interface is that over?
<amstan>
usb network card
<pulser>
I'm guessing some wired network adapter?
<amstan>
should work with most
<pulser>
Heh very nice - I have one sitting around
<amstan>
not sure if it's enabled in the release firmware builds though
<pulser>
Ah yes - would potentially be something you'd cut out for space I guess
<amstan>
and security
<pulser>
Well yeah :)
<amstan>
cross compiling...
naobsd has joined #linux-rockchip
<pulser>
Although I'm going by the assumption anyone accessing this screen is doing stuff
<amstan>
i did it once
<pulser>
Oh yes - I was looking at this - chromium fails to run if compiled using gcc 5.2
<amstan>
all i had was an arm gcc compiler, and an intel arch host
<pulser>
Me being me thinks the obvious solution is to fix this by compiling myself, rather than waiting on someone to fix it!
<amstan>
i did SOMEFLAGS=armgcc makepkg -ignorearch(or whatever) linux-veyron
<pulser>
Ah right so that's how I compile the kernel, yes
<pulser>
(I'm familiar with cross compile from Android so actually that wasn't a big issue) - I'm trying to find a good way to build an arch package cross compiled
<amstan>
it's not the "right" way to do arch packages, but it worked for the kernel
<pulser>
Since well, I don't fancy doing chromium on arm!
<amstan>
the right way to do it is to have an arm host, run makepkg there, and perhaps delegate some gcc workers to cross compilers on intel
<amstan>
but you still run out of ram on that arm host
<pulser>
Yeah they recommend distcc
<amstan>
especially for chromium
<pulser>
I was tempted to try qemu
<amstan>
so that's why i didn't bother looking at chromium yet
<pulser>
As apparently you can do that sanely on x64
<amstan>
warheadse tried qemu a few weeks ago, he gave up too
<pulser>
Oh dear
<pulser>
I was thinking that I'd use distcc, controlled by a qemu instance
<pulser>
To try get performance up on the gcc workers