<krzk>
I am following Linux kernel mailing list so the best way is to send to linux-samsung-soc@vger.kernel.org
<armoon>
thanks @krzk I will do the needfull thing
<wwilly>
hi
<wwilly>
by the way, is this linux exynos mailing list is really used?
<Wizzup>
not really
<krzk>
wwilly: I never looked there...
<Wizzup>
there already were/are better suited ones, we didn't realise that before
<wwilly>
i'm subscribed since 16-02-08 and have seen no cat there
<wwilly>
ah ok
<Wizzup>
chicken egg problem, too, of course
<wwilly>
Wizzup, you mean samsung-soc
<Wizzup>
yeah
<krzk>
last posts are from may 2015, without replies
<wwilly>
ah ha ok
<krzk>
yeah... so if you have any kernel related questions/discussions, then I thing samsung-soc is the best mailing channel
<armoon>
so we can have general talk on some issue over here
<krzk>
armoon: yes
<wwilly>
also, I remember that somebody attempt to push exynos5422 and exynos5800 boards to 2GHz, but refused because seems to be not safe
<armoon>
I was looking to some core change on exynos5422 usb 3.0 issue and I was wondering how to get the vbus setting to be configured
<wwilly>
in fact i'm running a few months at this frequency all the time, and no problem at all
<krzk>
wwilly: yes, Bartlomiej prepared a patchset for this. However this was not including all of possible variants and questions were how it will behave on some less popular batches of Exynos Soc.
<krzk>
There is no support for ASV in mainline (adjusting voltage per-batch of given SoC)
<krzk>
So at the end Bartlomiej gave up, I think
<wwilly>
uhm ok, by the way, not familiar with all terminology, what is a batch?
<armoon>
what are the pending thing to get exynos5422 odroid board to work effieciently
<krzk>
wwilly: by batch I mean different set of manufactured socs (differ e.g. by quality or on purpose). If you by 1000 Exynos5422 from Samsung, some of them for example might be working at 1.0V at given frequency but some at 1.05V
<wwilly>
isn't possible to get this by a revision number or something indicating whatever change?
<krzk>
wwilly: yeah, it is fused on the chip so you need a special driver which will read these values and set the voltages according to that value
<krzk>
wwilly: this is called in Samsung ASV - Adaptive Supplied Voltage or something like that. If you look at vendor code (Samsung LSI v3.10, Hardkernel's v3.10 is based on that) then
<krzk>
you will see asv drivers and tables in arch/arm/mach-exynos/...
<LiquidAcid>
krzk, so the chipid code doesn't cover that?
<krzk>
LiquidAcid: it is part of chipid, part of registers, lets say.
<LiquidAcid>
k
<krzk>
LiquidAcid: but in current mainline it is not handled in anyway
<LiquidAcid>
no, iirc the chipid code isn't upstream yet, or is it?
<krzk>
LiquidAcid: ha, good question... Pankaj Dubey was sending chipid driver but I think last revision v9 did not get in and he stopped...
<krzk>
but still you might have a driver and it depends what he does. This chipid serves only detection between Exynos (e.g. 4412 vs 5422)
<krzk>
but not between specific revisions of 5422
<armoon>
what will be the difference between Artik 5422 and Odroid 5422 ? do thet have different arch
<krzk>
armoon: The older Artik 10 works on some versions of 5422 with lower frequency. Beside that it's the same Exynos5422.
<krzk>
The new Artiks use Nexell chip
<wwilly>
at lower frequency for a particular reason, because of those voltage levels?
<armoon>
which are the development board for arm64 from exynos
<krzk>
wwilly: Actually I do not know. It might be because they target IoT so they want to reduce the power consumption or they use some versions of Exynos5422 which just cannot work on higher voltage/frequency. Like Odroid XU3-Lite.
<krzk>
armoon: there aren't any available publicly
<wwilly>
ok
<wwilly>
also krzk, I still not rework my patch for thermal sensors you reject because of "duplicated" code, and don't take time to rework thermal framework to allow multiple sensors per zone. I check the code for other board, they also apply my "kind of duplication" way
<wwilly>
but yeah, I admit is s***
<wwilly>
:)
<krzk>
wwilly: yeah, few days ago I looked at this again and wanted to implement one thermal zone with all CPU tmu sensors - which makes sense
<krzk>
wwilly: bindings are even describing this... but then when you look at the source code
<krzk>
it is hard-coded that only one sensor per thermal zone is supported now
<wwilly>
yep
<wwilly>
known problem as you have todo and fixme on the code...
<krzk>
with your initial approach I wonder how it would behave on conflicting readings, e.g. thermal zone0 staying cool, zone1 going hot. But you have only one cooling device (fan) shared between them. What will be the final choice?
<krzk>
wwilly: exactly... TODO
<wwilly>
saddly don't have enough knowledge to rework that, and more over, no time at all, I'm PhD guy, and in a rush for papers ah ha
<wwilly>
krzk, the cooling device policy applied to cluster
<wwilly>
for instance, step wise clock on step down each temperature violation poll
<krzk>
wwilly: but you have two or more different sources of change - each thermal zone will push in its way?
<wwilly>
so, each thermal zone poll, sometime you have a huge clock down, but came back on next cooling window
<wwilly>
krzk, it seems to be like this
<wwilly>
but I hard to figure out correctly that
<wwilly>
because they are grouped together by cooling device instance list
<wwilly>
I haven't dig enough on understanding the entire framework, but with the patch I propose, step wise and fan works fine
<wwilly>
and I also implemented my own strategy based on core and cluster task migration/mapping
<wwilly>
s/strategy/governor
<wwilly>
and I perform better héhé :)
<krzk>
wwilly: so unless someone will enhance the thermal-of framework to support multiple sensors, your patch should be resend and applied
<krzk>
it fixes real problem
<armoon>
I have some change I will share them some time in the future
<krzk>
armoon: great :)
<wwilly>
armoon, related to thermal?
<wwilly>
krzk, cool
<armoon>
yes
<wwilly>
ok, should you wait I resend my stuff first?
<wwilly>
at least I will have something published regarde my PhD, even if it's not a scientifi paper ah ha
<wwilly>
krzk, you want a rework of the patch or just a resend?
<krzk>
wwilly: rework in what kind of way? what do you mean?
<wwilly>
don't know, why the question :)
<wwilly>
I rechange again the patch for my purpose
<wwilly>
for instance I use only polling right know, as it perform better to keep the temperature bellow the trip point
<krzk>
wwilly: if you would do this in some smarter way to avoid duplication of all thermal zones - that would be good. However no one (including me) did it so far... so it is better to solve this problem even with the duplication
<wwilly>
and it was easyer for my own governor, but this is my own problem :)
<krzk>
wwilly: you mean, you changed from interrupt-driven (trip points) to polling mode?
<wwilly>
yes
<wwilly>
i put the interrupt step to zero, and use 250ms polling
<wwilly>
and it worked not bad
<krzk>
wwilly: so without this :). Send fix only to one problem - that thermal ignores work happening CPU5-7, if CPU4 is not busy
<krzk>
switching to polling is a different thing. You might send it as well but I rather prefer interrupt driven approach
<wwilly>
I put the interrupt to zero, because by dependency chain, or hard code in cpu I don't know, the old interrupt level was kept
<armoon>
perfomace on different cpufreq governer need to be considered
<genii>
It's nice to see this channel busy for a change
<krzk>
anyway you might send and let's see what people will say
<wwilly>
krzk, is it possible to define a constant and reuse it in multiple places?
<wwilly>
in dts file
<wwilly>
still don't understand this language, but honestly, I haven't dig to understand
<wwilly>
the documentation isn't easy as a Language C books if you know what I mean
<krzk>
yeah, we already do this through headers.
<krzk>
e.g. include/dt-bindings/pinctrl/samsung.h
<wwilly>
krzk, can you point me to the right approach?
<wwilly>
ah ok
<krzk>
ll include/dt-bindings/clock/exynos*
<wwilly>
armoon, can you elaborate?
<wwilly>
comparision between fair-share and stepwise?
<wwilly>
and new power allocator
<wwilly>
?
<armoon>
currently some how the when using cpufreq performace governer the clk % remain high on high temp
<wwilly>
krzk, I guess include/dt-bindings/thermal/thermal_exynos.h is a nice place for this constant trip points
<wwilly>
armoon, have you tried the patch I send long time ago?
<krzk>
wwilly: it depends what you want to put there :) . the headers should be used for example for constants which are shared between drivers and DTS (vide clock IDs, GPIO and interrupt levels) or for some re-usable and easier to read defines
<armoon>
I will check this out
<krzk>
wwilly: this should not be someyting configurable
<krzk>
wwilly: if you want to avoid duplication then you might play with putting some stuff under separate DTSI file and include in specific node (e.g. we do this with thermal configuration)
<wwilly>
trip points are configurable through sysfs
<armoon>
yes
<wwilly>
that the point I mess on this grammar/syntax of the language
<wwilly>
for instance, reuse trips { cpu_alert0 in multiple place in cooling-maps hang with error
<wwilly>
you can't reuse the same thing
<krzk>
wwilly: if you have phandles there (&cooling_dev1) then sometimes it is not that easy to re-use
<wwilly>
is why I guess other guys duplicate as well
<armoon>
you could avoid dupilcation by using thermal-sensors = <&tmu_cpu0 0 &tmu_cpu1 0 &tmu_cpu2 0 &tmu_cpu3 0>;
<wwilly>
armoon, you have the right id, but the thermal-of handling multiple sensor per zone note implemented
<wwilly>
idea...
<armoon>
all the trip get mapped to respective trips
<armoon>
sensors
<wwilly>
i tried that but themal-of don't take it
<wwilly>
ok krzk, I will resend the patch tomorrow morning
<wwilly>
uk morning
<armoon>
wwilly : your could observe this using tmon tool
<krzk>
wwilly: good
<wwilly>
ok armoon I will look at it too
Vasco is now known as Vasco_O
<armoon>
kzrk: what need to be implemented to get PSCI support for exynos5422
<wwilly>
c u tmw
wwilly has quit [Quit: Leaving]
<armoon>
ok thanks for your inputs. bye now
armoon has left #linux-exynos [#linux-exynos]
armoon has joined #linux-exynos
armoon has quit [Client Quit]
Anarchy has quit [Quit: Leaving]
nighty- has quit [Quit: Disappears in a puff of smoke]