<Viciouss>
mszyprow: about the p4note regulators, I already have always-on on all of them because I don't know the consumers and they would shutdown otherwise after a minute and bring the system to a halt
<Viciouss>
I'm not sure whether this is the case for all the missing regulators, but when I first booted without always-on on those that are undefined in the vendor sources, the system just froze after a minute
<mszyprow>
Viciouss: so if you don't define them in dts, reboot takes 2-3seconds, while when they are defined+always-on - it takes 10s?
<Viciouss>
indeed
<mszyprow>
Viciouss: hmm
<mszyprow>
Viciouss: that's indeed strange
<mszyprow>
Viciouss: do you have any log from that long reboot?
<Viciouss>
mszyprow: it looks like I shouldn't mess with whatever the bootloader has setup in the first place :-)
<mszyprow>
Viciouss: it looks so
<mszyprow>
Viciouss: maybe some of them are turned off by bootloader
<Viciouss>
There is no output after the serial cuts out, the last thing I can see is a line stating that the device is rebooting
<mszyprow>
Viciouss: I really have no idea
<mszyprow>
Viciouss: I would probably skip defining them if that causes the issue
<Viciouss>
mszyprow: it looks like the device is completely off in between the reboot and then somehow gets a signal to boot again, as opposed to just doing a quick power cycle. I could imagine that this interferes with reboot modes but I haven't tried it yet
<mszyprow>
Viciouss: well, maybe it boots again because the usb/uart cable is connected?
<Viciouss>
mszyprow: I could try whether it stays off if there is nothing connected to the port, but that would be even worse then
LiquidAcid has quit [Remote host closed the connection]
<Viciouss>
knowing what the bootloader does and why would be really helpful but that's out of reach, maybe I should start a petition to ask for documentation for these old devices to be released, who knows how it turns out
PabloPL has joined #linux-exynos
<krzk>
Relying on undocumented behavior of bootloader is not good in long term as you won't be able to switch to newer U-Boot. Although usually there is no easy way of this anyway...
<krzk>
But let's be sure we talk about same thing - don't touch existing regulators in DTS. We talked about undefined ones. Keeping them always-on without constraints should not affect anything.
<krzk>
Viciouss: when you boot without these regulators, what do you have in /sys/kernel/debug/regulator/regulator_summary
<Viciouss>
one minute, I'll check
<Viciouss>
The biggest issue for all the exynos4 phones and tablets from Samsung is s-boot anyway, if I remember correctly the mmu problem is affecting most if not all of them
<Viciouss>
if I define them, then the use column is set to 1 because of the always-on and leaving this option out will result in the driver disabling the supplies some seconds after the boot which freezes the system because some of are apparently needed. the only feasible way to find out which of the regulators should be on would probably be to reverse engineer the bootloader
_whitelogger has joined #linux-exynos
PabloPL has quit [Quit: PabloPL]
LiquidAcid has joined #linux-exynos
<krzk>
Viciouss: I think we misunderstood each other. mszyprow proposed to keep always-on, on all regulators which were not defined
<krzk>
Viciouss: this will mean that you will have them in DTS fod proper HW description, but kernel won't turn them off, so it will be the same as before.
<mszyprow>
krzk: if always-on doesn't work, I would simple remove those undefined regulators
<mszyprow>
krzk: if this solves the reboot issue
<krzk>
Yeah, but it should work.
<krzk>
I think Viciouss was comparing cases when they do not have always-on.
<krzk>
"... and leaving this option out will result ... which freezes the system"
<krzk>
Viciouss: and the way to figure out which have to be always-on, is to try turning off one by one, till you have minimal on configuration
<Viciouss>
krzk: I will check later today, could be a lot of device reboots though, I hope that this doesn't mess with the hardware somehow
<Viciouss>
mszyprow: btw I also had a look at the ehci and display, I'll remove the ehci node for now as it is not yet used, I'll have a closer look at what phys I need when I get to it. for the display, it's simple but not that simple. I'd prefer writing a full driver in a separate patch if that's ok
mszyprow has quit [Ping timeout: 264 seconds]
<Viciouss>
krzk: When I'm done with the regulators, I'll have a list of some that are used and needed and some that are not in use at all and never will be, what would be the advantage of having the latter ones in the DT then? Every time I boot the kernel I'd see a message that they have been disabled which seems unnecessary.
<Viciouss>
Actually, thinking about it, I take this back. It could be that I have to enable one of those later on as there are still pieces of the DT missing which could be powered by one of those regulators that I will disable now.