03:08 <naobsd> akaizen: probably no

03:46 <TonyTony> naobsd, as you see, we cancel to modify android 4.2.2 to RK3288. ;P

03:47 <TonyTony> naobsd, RK also suggest us don't do that or they won't give service.

04:54 <naobsd> TonyTony: sounds reasonable to me...

04:59 <TonyTony> naobsd, ah. and today I want to talk about how to built-in a temperature sersor in kernel ? it based the i2c bus.

05:00 <TonyTony> now It can works fine on userspace by /dev/i2c-0. I want to find some subsystem about this.

05:00 <TonyTony> I want to make kernel driver for that.

05:01 <TonyTony> the hwmon subsystem seems like for the sensor. but I can not ensure.

05:17 <naobsd> check existing driver in kernel source tree & enable it

05:28 <TonyTony> the chip I used have not existed in kernel source tree, I want to know which subsystem I should use for it.

05:28 <TonyTony> Do you know the hwmon sub-system well ?

05:29 <TonyTony> I can't sure if it is the sub-system I find.

05:41 <naobsd> check similar device driver

05:43 <TonyTony> okay, thanks.

15:57 <mmind00> jap ... also einmal ... wir jagen aber seit ein paar Tagen ein reboot-Problem das jemand auf dem Cortex-A9 sieht ... d.h. nach nem reboot gibts dann paging fehler: https://paste.mniewoehner.de/uER/

15:58 <mmind00> sorry wrong channel

16:06 <c0d3z3r0> mmind00: I have some more news on that

16:07 <c0d3z3r0> I trieg to set vdd_arm to 1,0V shortly before reset. Though that is not the way to go it worked. The right way seems to be to disable cpufreq and lock the frequency so the voltage is 1.0V

16:08 <c0d3z3r0> that's what the rkchrome guys did

16:08 <c0d3z3r0> but I don't really know how to do that in mainline kernel

16:08 <c0d3z3r0> since there is no rockchip-cpufreq driver

16:10 <mmind00> c0d3z3r0: does this help then?

16:11 <mmind00> c0d3z3r0: the german line above comes from a chat about a possible issue in the smp-code for the rk3188

16:12 <c0d3z3r0> not always because if the frequency is 1,6GHz at the time of setting vdd_arm to 1.0V it crashes before power cycle. When I first set the power cycle bit and then the voltage that works because there are 8ms between setting the register and the actual power cycle

16:13 <c0d3z3r0> It doesn't work always. Sometimes there is a crash so maybe that is a timing problem

16:13 <c0d3z3r0> here is the patch https://paste.mniewoehner.de/NJS/

16:13 <c0d3z3r0> line 36 is new

16:14 <c0d3z3r0> the rest is the same as on the mailing list

16:15 <c0d3z3r0> that is the patch from rkchrome kernel https://paste.mniewoehner.de/fZndoZ/

16:28 <mmind00> c0d3z3r0: can you try changing headsmp.S to https://bpaste.net/show/50cbd168871e [state before introduction of the rk3288 supper] and see if the problem persists?

16:28 <c0d3z3r0> with or without my 1.0V workaround?

16:29 <mmind00> I'd guess without, i.e. pristine kernel :-)

16:30 <c0d3z3r0> ok

16:46 <c0d3z3r0> mmind00: interesting… the voltage after reboot is 1,35V but there is no kernel panic even after multiple reboots. it also fixes the kernel bug that happend when running "memtester 1800"

16:47 <c0d3z3r0> what exactly does the patch change?

16:48 <mmind00> c0d3z3r0: great ... as you can see in headsmp.S v7_invalidate_l1 is supposed to be called conditionally on Cortex-A9 smp bringup

16:49 <mmind00> c0d3z3r0: both the conditional as well as the branch itself is faulty it seems ... so the diff above reverts it to the state it had before the RK3288 was added

16:49 <mmind00> c0d3z3r0: there is a bigger patch in the works on the lists that changes this in a much broader way

16:49 <mmind00> c0d3z3r0: http://www.spinics.net/lists/arm-kernel/msg419921.html

16:51 <c0d3z3r0> mmind00: thanks :) can you also explain why it crashes only when running at 1.35V and not 1.0V?

16:51 <mmind00> c0d3z3r0: not really, I'd guess it is more a random thing

19:45 <c0d3z3r0> mmind00: after some tests even with overclocking to 1.92 it seems to run stable with the patch applied ;)

19:47 <mmind00> with my diff to headsmp.S or with mailinglist-patch I linked to?

19:47 <c0d3z3r0> yep

19:47 <c0d3z3r0> ah uhm the first

19:47 <c0d3z3r0> :D

19:49 <mmind00> c0d3z3r0: can you try https://github.com/mmind/linux-rockchip/commits/tmp/russell_cache

19:49 <mmind00> c0d3z3r0: I'm fighting a different fight currently, so haven't had time to test yet

19:50 <c0d3z3r0> I'll try that in some minutes

19:50 <c0d3z3r0> and if you can give me a little hint how to do that I would also create a patch for the clock timer issue

20:39 <c0d3z3r0> mmind00: no crashes or kernel panics with the patch

20:39 <mmind00> yay \o/

20:42 <mmind00> c0d3z3r0: don't know if you're subscribed to the linux-rockchip list and would've gotten the patch from there, but if you have it somewhere you could send a Tested-by tag as reply to it

20:43 <mmind00> c0d3z3r0: I haven't much insight into the timer issue though ..

20:44 <c0d3z3r0> mmind00: this list? http://lists.infradead.org/mailman/listinfo/linux-rockchip

20:48 <mmind00> c0d3z3r0: yep

21:02 <c0d3z3r0> mmind00: done

21:17 <c0d3z3r0> wtf… Message has a suspicious header

21:30 <mmind00> hehe ... sadly it doesn't say which one ... but I've authorized your mail ;-)

21:31 <c0d3z3r0> mmind00: thx :)

21:38 <mmind00> c0d3z3r0: as I'm just seeing this ... could you do this again, but with a reply-all :-)

21:38 <mmind00> i.e. it should reach all people who originally got the mail

21:39 <c0d3z3r0> I didn't get the mail because I subscribed it after that patch :/

21:39 <c0d3z3r0> so I just copied it to a new "reply" mail

21:39 <mmind00> ah ok :-)

21:40 <mmind00> I'll do a reply anyway ... so I'll just paste your response into it

21:40 <c0d3z3r0> ok

21:41 <c0d3z3r0> time for bed now.. gn8

21:42 <mmind00> gn8

22:01 <naobsd> seems good news :)

22:02 <naobsd> I don't understand what happened at rockchip_secondary_startup, but if L1 cache is not invalidated properly, random crash after reboot is reasonable