paulk-collins has quit [Remote host closed the connection]
amitk has joined #linux-exynos
dlezcano has quit [Ping timeout: 248 seconds]
luisbg has quit [Ping timeout: 250 seconds]
luisbg has joined #linux-exynos
luisbg has joined #linux-exynos
luisbg has quit [Changing host]
dlezcano has joined #linux-exynos
paulk-veyron-min has joined #linux-exynos
paulk-veyron-min has quit [Remote host closed the connection]
dlezcano has quit [Ping timeout: 265 seconds]
dlezcano has joined #linux-exynos
Turl has quit [Ping timeout: 255 seconds]
Turl has joined #linux-exynos
Turl has quit [Ping timeout: 272 seconds]
Turl has joined #linux-exynos
Turl has quit [Ping timeout: 248 seconds]
Turl has joined #linux-exynos
ayaka_ has joined #linux-exynos
ayaka has quit [Read error: Connection reset by peer]
ayaka_ is now known as ayaka
Turl has quit [Excess Flood]
Turl has joined #linux-exynos
paulk-collins has joined #linux-exynos
dlezcano has quit [Remote host closed the connection]
prahal has joined #linux-exynos
dlezcano has joined #linux-exynos
isaque has joined #linux-exynos
dlezcano has quit [Remote host closed the connection]
dlezcano has joined #linux-exynos
dlezcano has quit [Ping timeout: 248 seconds]
dlezcano has joined #linux-exynos
masta has quit [Read error: Connection reset by peer]
masta has joined #linux-exynos
TheSeven has quit [Disconnected by services]
[7] has joined #linux-exynos
Vasco_O is now known as Vasco
dlezcano has quit [Ping timeout: 248 seconds]
dlezcano has joined #linux-exynos
LiquidAcid has joined #linux-exynos
<LiquidAcid>
ndufresne, i remember you mentioning some "bus speed" kernel log spamming a few days ago (from mmc subsystem) -- do you also see some voltage/regulator warning with that?
<ndufresne>
LiquidAcid: not that I recall
<LiquidAcid>
k
<ndufresne>
I have demoted the from info to debug that trace now, as it didn't seem to have any side effect
<ndufresne>
From my understanding, it's raising the mmc speed above the HW capacity, and keep trying every second
<ndufresne>
there was some changes in that regard, maybe they got it wrong for the old 4412, who knows
<LiquidAcid>
<ndufresne> From my understanding, it's raising the mmc speed above the HW capacity, and keep trying every second <- i don't think so
<LiquidAcid>
it's introduced by commit 65257a0deed5aee66b4e3708944f0be62a64cabc
<LiquidAcid>
i think this bit is just plain wrong:
<LiquidAcid>
"The warnings are caused because of bit shift which is used to filter spamming message for CONFIG_MMC_CLKGATE, but the config is already removed. So this patch just removes the shift."
<ndufresne>
so probably that it was tracing the same info over and over
<ndufresne>
LiquidAcid: anyway, it's spammy now, at least on Exynos 4412
<LiquidAcid>
this part is broken of course: (clock << div) != slot->__clk_old
<LiquidAcid>
but the check should definitely be put back there
<LiquidAcid>
i'm not even sure what clock << div is supposed to be
<ndufresne>
it's a multiplication, so div is odd in there
<LiquidAcid>
where is the multiplication?
<LiquidAcid>
or do you mean a << b is a * 2^b ?
<ndufresne>
yes, but then I realize it might be scaling up the clock by it's divider
<ndufresne>
not that I yet understand the goal
<ndufresne>
LiquidAcid: basically, I think the check is trying to check if something have changed, but the clock value are not in the same scale
* ndufresne
need more context
<ndufresne>
so basically, the logic was trace this if "force_clkinit" or if the clock speed have change, no idea why they didn't save the unscaled clock, as clearly _clk_old is unused for anything else
<ndufresne>
and got no idea why they figure-out that removing the check was a solution
<ndufresne>
LiquidAcid: and the initial warning is most likely before you need a 64bit value to store those scaled up clock values (like most clock values really)
<ndufresne>
we've got similar patches from Samsung proposed for GStreamer, and a lot of them needed serious rework, but just like this one, some made it through and we only found the side effect later
<LiquidAcid>
ndufresne, my approach would be to just store the divider and check against it
<LiquidAcid>
ndufresne, might just well ask another question (since you own a u2/u3)
<LiquidAcid>
did it ever happen to you that the device didn't boot after connecting power? especially with nothing else but power connected (no eth, no hdmi, etc.)
<ndufresne>
sounds familiar, actually iirc it happenned that I had to unplug the USB/Serial to boot again
<ndufresne>
but no recently, though I have hdmi and eth connected
<ndufresne>
I suspected a problem on HK side, so didn't bother anyone at the time
<LiquidAcid>
ndufresne, did you have the uart connected at that time?
<ndufresne>
yes
<ndufresne>
it's rare that I don't have anything at all connected
<LiquidAcid>
maybe i should describe what happens for me
<LiquidAcid>
this only happens in the aforemetioned situation (nothing connected)
<LiquidAcid>
when i connect the uart _after_ the "hang", i'm actually on the u-boot prompt (sending a <ENTER> over the line usually gives me a "<random chars> command not found" message)
<LiquidAcid>
so despite nothing being connected to the uart, some garbage is read from it which halts u-boot's autoboot
<LiquidAcid>
i just wanted to know if i'm the only one seeing this on the exynos4412 based odroids
<ndufresne>
I notice the garbage on the uart multiple time
<ndufresne>
it messes up with kgdb sometimes
<LiquidAcid>
so you see it not only during startup, but also while the kernel is running?
<ndufresne>
no, not when it's running, but right before boot, and after a kernel panic
<ndufresne>
it messes gdb due to the queued data, which isn't text, anyway, probably not realted
<LiquidAcid>
hmm, so it does happen on the u2 as well
<LiquidAcid>
i'm currently "fixing" this with keyed autoboot, but i was hoping for a "cleaner" solution
<LiquidAcid>
especially since flushing the uart fifo doesn't fix things
Vasco is now known as Vasco_O
masta has quit [Read error: Connection reset by peer]