<zear>
and well, gameplay is better than crysis :D
<bartbes>
actually
<bartbes>
I thought crysis was a great game
<zear>
yeah, but hella buggy
<bartbes>
meh
<bartbes>
not here
<zear>
i have a pretty strong pc
<zear>
and (especially the addon) was really, really buggy
<zear>
you could die by stepping on a barrel
<zear>
wtf
<bartbes>
never had that..
<bartbes>
though.. what was it called again, was less good story-wise
<bartbes>
it was more like.. a few extra levels
<bartbes>
warhead, that was it
<zear>
yeah, that's it, it was damn buggy
<mth>
larsc: I think reading of clocks should be protected by locking if we want to support PLL freq changes
<mth>
since the new dividers will be written before they become effective
<mth>
even if we would store the rounded frequencies in variables in addition to registers, there is no way to atomically update all clocks together with the PLL register
<mth>
also, the entire PLL freq change sequence would have to occur in a single big lock, not in a series of small locks on individual clock writes
<mth>
larsc: "gpio" in debugfs shows invalid info for pins in function mode, for example backlight is shown as input
<larsc>
can't do anything about it
<larsc>
gpiolib does not know about specialfunction pins
<larsc>
and input is the default
<mth>
the drivers could set the direction together with the function, but I guess that's a bit overkill just to get the debug info correct
<qi-commits>
Maarten ter Huurne: jz4740: clock: In clk_set_parent(), preserve clock enabled/disabled state. http://qi-hw.com/p/qi-kernel/5950c76
<mth>
debug/mips/unaligned_instructions (debugfs) is increased by 34 per second, does anyone know if this is expected or strange?
<mth>
larsc: a possible way to deal with PLL freq changes vs divider changes is to tie the PLL freq to the upper limit of the CPU speed rather than the target CPU speed
<mth>
for example, if you set the scaling_max_freq to 400 MHz, the PLL will be set for 400 MHz, even if the target freq is only 100 MHz at the moment
<mth>
that way, automatic CPU freq switching will avoid the relatively costly PLL reprogramming and will use the lower overhead divider changes only
<mth>
the down side of that is that in the upper part of the spectrum, there are not a lot of dividers to choose from
<mth>
meaning that with the maximum at 400 MHz, there is nothing between 200 and 400 possible
<mth>
but automatic CPU freq switching is for saving power in situations where there is a low CPU load
<mth>
while overclocking is done from gmenu2x by users who know that a certain program will only run well at a higher maximum speed
<kristianpaul>
kernel panic - not syncing: No init found..