00:06 <naobsd> amstan: sorry, I cannot understand your question

00:06 <amstan> "[20:46] <TonyTony> naobsd, as you see, we cancel to modify android 4.2.2 to RK3288. ;P"

00:07 <amstan> ^ what does that mean?

00:07 <naobsd> he gave up android 4.2.2 on rk3288, that's all...

00:07 <amstan> why?

00:07 <amstan> rk told them to?

00:07 <naobsd> maybe too hard?

00:07 <amstan> oh

00:08 <naobsd> rk just doesn't support, no try, no give up

00:08 <naobsd> no reason to do it

00:08 <naobsd> (for me)

00:11 <naobsd> it may not too hard, but there is no reason to do it

00:11 <amstan> why do people like android anyway?

00:13 <naobsd> because they like it?

00:14 <amstan> my ideal application for these sticks is archlinux with kodi on there playing videos from a network share

00:14 <amstan> i find android to be lacking in that regard

00:17 <naobsd> I want to use NetBSD if possible

00:17 <naobsd> but generally my NetBSD machines cannot play videos (or doesn't have video output)

00:18 <naobsd> I don't see online free videos so much

00:20 <naobsd> I have BD player to see BD movies. it supports DLNA and youtube too, good for watching movies/personal videos on TV at living room

00:21 <naobsd> I sometimes use Android phone to see videos

00:22 <amstan> i don't like seeing ads

00:23 <naobsd> I just ignore ads :)

00:23 <naobsd> I'm lazy so I don't use something which blocks ads... I have no interest about how to block ads ;)

00:26 <naobsd> I want to try Chrome OS

00:27 <amstan> well, get yourself an rk3288 machine

00:27 <amstan> then you can both try chromeos and also hack on rk3288

00:37 <naobsd> yes

00:38 <naobsd> what I want is one with LCD and keyboard for daily use ;)

00:41 <amstan> naobsd: so... either of these: http://www.walmart.com/ip/44389793 http://www.amazon.com/ASUS-Chromebook-C201PA-DS01-11-6-Inch-Laptop/dp/B00VQP3DNY

00:41 <amstan> or wait for this: http://www.theverge.com/2015/3/31/8314907/asus-chromebook-flip-convertible-touchscreen

09:29 <mmind00> amstan: you're probably asleep now, but I have working wifi on pinky and jerry now ... the problem was easier than imagined, as simply the iodomain driver was missing ... see PM/Avs patch from yesterday

15:41 <c0d3z3r0> naobsd: you said rockchip-timer should work for rk3188. that is the arch timer used with rk3288, right?

16:07 <naobsd> c0d3z3r0: arch timer is handled by arch timer driver

16:08 <naobsd> c0d3z3r0: rockchip timer is 64bit timer in RK3188 and rk3288

16:12 <c0d3z3r0> naobsd: ah ok what is that local-/global-timer in rk3188.dtsi? it's not in rk3288.dtsi

18:10 <mmind00> c0d3z3r0: arch-timer and global/local-timer are the timers integrated into the ARM-core (arch-timer from Cortex-A15 onward (A7, A17) and the global/local-timer limited to A9 I think)

18:31 <c0d3z3r0> mmind00: so I have to remove them when adding rockchip-timer?

18:33 <mmind00> c0d3z3r0: first of all you would need to adapt the rockchip timer driver somehow ... it currently only implements a broadcast clockevent device

18:45 <mmind00> c0d3z3r0: the easier option might be fixing the global

18:45 <mmind00> + local-timer

18:46 <mmind00> c0d3z3r0: both currently do not check their source clock at all ... but both have a "prescaler" field meant to adapt the interval length it seems: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407e/JHBCHJID.html

18:48 <mmind00> c0d3z3r0: so essentially, add clk_get and friends and a clock notifier that gets fired when the core-periph clock changes and adapts the prescaler

18:50 <mmind00> c0d3z3r0: ok scrap parts of this ... the global timer actually does clk_get the clock, but does not handle it changing, so essentially needs just the clock notifier redoing the rate calculation [without touching the prescaler]

18:54 <c0d3z3r0> mmind00: ok, I'll see if I get it working :) mh what about drivers/clocksource/rockchip_timer.c ? isn't that already working for rk3288?

18:54 <mmind00> c0d3z3r0: drivers/clocksource/timer-sun5i.c seems to have the same "issue" so you might get inspiration from there (in terms of clk_notifier)

18:55 <mmind00> c0d3z3r0: as I said, rockchip_timer currently only handles a broadcast clockevent timer, what you would need is a global clocksource and additional per-cpu clockevent devices

18:56 <mmind00> c0d3z3r0: and adding new clocksource drivers might get you shouted at ;-)

18:57 <mmind00> c0d3z3r0: cadence_ttc_timer.c might be second nice example there

19:00 <c0d3z3r0> mmind00: thanks :) let's see if I can manage that