isaque has joined #linux-exynos
isaque has quit [Quit: isaque]
paulk-collins has joined #linux-exynos
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."
<LiquidAcid> i was thinking about a different issue though, currently hitting this: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/core.c#n221
<ndufresne> ah, your probably right
<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]
masta has joined #linux-exynos
isaque has quit [Quit: isaque]
_whitelogger has joined #linux-exynos
steev has joined #linux-exynos
paulk-collins has quit [Quit: Leaving]
ojn has joined #linux-exynos
amitk has quit [Quit: leaving]
LiquidAcid has quit [Quit: Leaving]
Wizzup has quit [Ping timeout: 244 seconds]
Wizzup has joined #linux-exynos
ayaka has quit [Ping timeout: 248 seconds]
prahal_ has joined #linux-exynos
prahal has quit [Ping timeout: 244 seconds]
Wizzup has quit [Ping timeout: 250 seconds]