ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at http://linux-rockchip.info | Logs at http://irclog.whitequark.org/linux-rockchip | ML at http://groups.google.com/group/linux-rockchip
cristian_c has quit [Ping timeout: 250 seconds]
Ueno_Otoko has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
nighty-_ has joined #linux-rockchip
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]
cristian_c has joined #linux-rockchip
JohnDoe_71Rus has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
<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> Aha, not set in config
<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> Ahhh
<pulser> Thanks - that explains it perfectly
<pulser> I was able to compare the device trees fine, but wondered about this - that makes a lot of sense then to do procedurally
<pulser> Awesome - found the accelerometer configuration - I'll need to get familiar with these then :) thanks
<amstan> pulser: if you want a pretty full featured config for the 3.14 tree, i generally use https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-veyron/config
<amstan> thanks to leming
<amstan> it even boots systemd
<pulser> Ah yea, that's a good shout too
<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
<pulser> But the qemu would still be a bottleneck
<amstan> in terms of the gcc bug.... jwerner(our coreboot guy) found this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67701
<amstan> i'm hoping that's what the issue is with all the failed compiles on gcc 5.2
<amstan> anyway, there's more action about that in #archlinux-arm if you wanna go there
<pulser> Wow okay....
<pulser> I shall thanks
<pulser> That's crazy compilation there!
<amstan> yeah, not sure what that's about, how it can get so bad
<pulser> Yeah - 4.9 seems absolutely fine... No idea what on earth it's trying to do on 5.2
nashpa has quit [Ping timeout: 252 seconds]
naobsd has quit [Quit: naobsd]
sandy_ has quit [Quit: Page closed]
naobsd has joined #linux-rockchip
naobsd has quit [Client Quit]
<karlp> arch is doing weird things, someone in cortex-m world found that the arch gcc 5.2 doesn't even include cortex-m7 support that was added in 5.1
<amstan> karlp: ah! so that's why i couldn't compile opencm3
<amstan> karlp: i hit that a few weeks ago, luckly i was only using cortec-m0 and it went past that point before it crashed
<amstan> i guess you know a little more about that :)
<karlp> well, I just said, "arch problem, juse g-a-e like we recommend"
<karlp> I was kinda surprised that sexycoolnewshiny arch would have such busted gcc, but, well... "someone else's problem"
cristian_c has quit [Quit: Bye]