<ElBarto>
does linux disable a regulator if it's not referenced in the dts ?
Mangy_Dog has joined #linux-sunxi
<montjoie>
I think that if linux dont know the regulator it cannot touch it, but the AXP driver could probably do something like "disable all then ..."
<ElBarto>
in FreeBSD I don't care if the regulator isn't in the dts
<ElBarto>
I just disable every registered regulator that isn't always_on and don't have consumer
<mripard>
iirc the logic is that if it's in the DTSI, enabled, but no one took a reference on it
<mripard>
linux will disable it
<mripard>
(unless there's always-on, of course)
<mripard>
hmm
<mripard>
s/DTSI/DT/
<ElBarto>
so if it's not in the dts linux will not disable it
<ElBarto>
ok that's where we are different
<mripard>
that's what I remember yes
<ElBarto>
now I need to find why it is needed ...
<mripard>
but it's pretty much always in the DT, we have all the regulators in the AXP DTSI
<mripard>
so if you're using it, you're listing them all
<ElBarto>
for cubieboard that's true
<ElBarto>
I'm sure that freebsd will fail on the a10-olinuxino since it doesn't include the axp209.dtsi
<ElBarto>
and linux seems to be ok the on kernelci page
<ElBarto>
mine is unfortunately dead so I'll just look away and pretend I didn't see that :P
victhor has quit [Read error: Connection reset by peer]
victhor has joined #linux-sunxi
superprower has quit [Ping timeout: 258 seconds]
gudvinr has joined #linux-sunxi
gudvinr has quit [Remote host closed the connection]
montjoie has quit [Quit: Lost terminal]
random_yanek has quit [Ping timeout: 260 seconds]
matthias_bgg has quit [Ping timeout: 240 seconds]
random_yanek has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
bbrezillon has quit [Quit: WeeChat 2.7]
bbrezillon has joined #linux-sunxi
montjoie has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 268 seconds]
matthias_bgg has joined #linux-sunxi
mrpfilser has quit [Quit: leaving]
merbanan has quit [Ping timeout: 265 seconds]
malestorm has quit [Quit: malestorm]
merbanan has joined #linux-sunxi
<ElBarto>
montjoie: I don't understand some stuff in the bootlog from kernelci
<ElBarto>
like [ 1.848069] ldo3: supplied by regulator-dummy
<ElBarto>
what does that mean ?
<ElBarto>
[ 2.117165] ahci-sunxi 1c18000.sata: 1c18000.sata supply ahci not found, using dummy regulator
<ElBarto>
[ 2.125951] ahci-sunxi 1c18000.sata: 1c18000.sata supply phy not found, using dummy regulator
<karlp>
those are informative aiui, not probelmatic
<ElBarto>
ahci-sunxi doesn't use the target-supply prop ?
<karlp>
well, depends, did you _mean_ to have explicit ones set?
<ElBarto>
or does it simply looks for other generic-ish prop as well ?
<KotCzarny>
isnt dummy regulator kind of noop ?
<KotCzarny>
ie. if bootloader enabled it, it doesnt touch it
<ElBarto>
karlp: the dtb have the regulator in target-supply, so I don't understand those lines
<mru>
you get those messages if there is no explicit regulator for the device specified in DT
<mru>
that's often the case when the board has them connected to an always-on power rail
<ElBarto>
that's not the case here, it's a gpio controlled regulator
<mru>
then you have to specify it properly
<ElBarto>
ah ok, based on the bindings there is two other opptional regulator (those two)
<ElBarto>
ahci-supply and phy-supply
<ElBarto>
so it's good here
<mru>
yeah, your device may be using a single supply for everything
<ElBarto>
KotCzarny: what do you mean by 'if bootloader enabled it, it doesnt touch it' ?
<ElBarto>
well I understand what you mean, but how is that represented in the dt or how can you know if it's enabled by the bootloader ?
<ElBarto>
like testing if the regulator is enabled in the pmic you mean ?
<KotCzarny>
like not doing anything
<ElBarto>
so if a bootloader enables all the regulators even if they are not needed linux will not disable them ?
<KotCzarny>
that's my guess
<ElBarto>
mripard seems to think otherwise
<KotCzarny>
unless you have some routine that goes over everything and disables
<mru>
if the kernel knows about a regulator, it will be disabled if nothing uses it
<ElBarto>
right
<ElBarto>
question is what is needed for a regulator to be known
<mru>
a DT entry and a driver
<ElBarto>
just being in the DT ? having some properties ? etc ...
<ElBarto>
ldo3 have no other property except for the name
<ElBarto>
so would that counts as a regulator that linux will disable ?
<mru>
is that the ldo3 that's part of the axp pmic?
<ElBarto>
I'm starting to wonder if it's not just another "weird bug" (tm) in FreeBSD
<KotCzarny>
maybe disabling ldo3 results in some power surge that resets axp209 ?
<ElBarto>
because I don't see anything that could be powered off by this regulator
<ElBarto>
u-boot doesn't look like it will enable it too
<ElBarto>
but it seems that it's enabled by default
<KotCzarny>
try disabling ldo3 in uboot shell?
<ElBarto>
I don't have the board, this makes debugging more ... interesting :)
<ElBarto>
but I've suggested that to the bug reported
<KotCzarny>
do you have any a10 board?
<ElBarto>
mine is dead (Olinuxino)
<KotCzarny>
it might be a10/axp209 related in general
<ElBarto>
but axp209 is on all a20 boards
<ElBarto>
and I have a few
<ElBarto>
so I'll do some tests
<willmore>
ElBarto, looking at the schematic, I see nothing tied to the LDO3 output, just a cap to ground. Could it be something in the data sheet of the power chip? It may use LDO3 as the source of another regulator--which would then depend on LDO3 being enabled to function.
<ElBarto>
could be, I'll do test later this afternoon to see how my bananapi react when I disable the regulator
<willmore>
I see nothing in the datasheet to support that, though.
<willmore>
All I can say is that the datasheet suggests using LDO3 for running PLLs and DRAM. It's got a drive ability of 200mA.
lurchi_ is now known as lurchi__
jstein has joined #linux-sunxi
gaston1980 has quit [Remote host closed the connection]
<kevans91>
yeah, it's incredibly unclear to me why turning off ldo3 kills my board and I've unfortunately ran out of time to debug it today
gaston1980 has joined #linux-sunxi
florian_kc has joined #linux-sunxi
florian has quit [Read error: Connection reset by peer]
<megi>
heh, axp803 control is fully in the hands of ATF on A64?
<megi>
sort of a bummer
<megi>
looks like there's no way to read AXP battery/charger info from u-boot
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
reinforce has quit [Quit: Leaving.]
selfbg has quit [Remote host closed the connection]
diego_r has quit [Ping timeout: 260 seconds]
bjne has quit [Ping timeout: 265 seconds]
matthias_bgg has quit [Quit: Leaving]
diego71_ has joined #linux-sunxi
diego71 has quit [Ping timeout: 265 seconds]
ganbold_ has joined #linux-sunxi
ganbold has quit [Ping timeout: 268 seconds]
mymy has joined #linux-sunxi
mymy has quit [Client Quit]
tllim has joined #linux-sunxi
Mylene has joined #linux-sunxi
<anarsoul>
megi: yeah, because u-boot requires regulator driver in SPL but A64 SPL is pretty close to 32kb
<anarsoul>
megi: in theory you can add a command akin to i2c to read the registers
<megi>
I assume this is also why ATF enables all regulators that have devices attached to them in DT
<megi>
because u-boot has no way to do it
<anarsoul>
yes
<megi>
selectively
<anarsoul>
I think you still can implement axp803 battery driver
<anarsoul>
it won't conflict with ATF
<megi>
btw, I'm close to trying my first 5.5-rc kernel on PP, just cherry picking the last patches from linux-next now, and almost ready to try :)
<anarsoul>
:)
<megi>
I'll push it out to my tree, as soon as it's tested
<megi>
btw, I overclocked SD card interface to 2x the clock and it was able to read the partition table
<megi>
45MiB/s :)
<megi>
if it turns out to be stable, I may keep it in u-boot at least, to get faster boot times
<anarsoul>
it won't be stable with all the cards
<anarsoul>
also it may kill the card
<megi>
hmm
<megi>
ok, so that's one thing off the table
reinforce has joined #linux-sunxi
BenG83 has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 268 seconds]
bjne has joined #linux-sunxi
nexgen has joined #linux-sunxi
<montjoie>
ah ah ah sun8i-ce turbo patch near ready
tnovotny has quit [Quit: Leaving]
<tuxd3v>
montjoie, you mean fbturbo?
florian_kc has quit [Quit: Leaving]
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
Benjojo has quit [Ping timeout: 245 seconds]
Benjojo has joined #linux-sunxi
<ElBarto>
so it turns out that my problem with LD03 was FreeBSD twi driver fault all along (which I wrote ...)
<ElBarto>
we ended up in some case writing 0 to the axp regulator control register
<willmore>
That's not a good idea.
gudvinr has joined #linux-sunxi
<ElBarto>
nope :)
florian has joined #linux-sunxi
return0e has joined #linux-sunxi
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
<gudvinr>
Hello, everybody.I've got A13 board with RTL wifi chip and NAND flash installed. It has old debian image which isn't supported anymore.So I want to put something more fresh but unfortunately no one has any ready to flash images (and I guess there's some reason for that I don't know about yet).Since I am not really into serious embedded stuff
<gudvinr>
(though I quite experienced Linux developer) I'd really like to get some help or hints where to move.At the very end it will be preferrable to build some flashable image that possible to load using FEL.I guess good ol' debian is a way to go and my first thoughts was to start with armbian since it already has prerequisites for sun5i and move from
<gudvinr>
here.Though I think it doesn't have in-memory overlay like openwrt so I guess it is another issue to solve (because I don't want to cripple flash too fast and then resolder).After I read materials at linux-sunxi it became apparent that there's some key points that I should look into: u-boot support, NAND support and device-specific dts. VPU support
<gudvinr>
is good but not a main goal.Am I missing something else or maybe there's something important?Thanks.
<gudvinr>
Yes, I am aware about number of "to be ready soon™" initiatives out there. But I have an interest in building firmware image rather than to rely on someone who is also unreliable as myself.
ldevulder has quit [Ping timeout: 240 seconds]
dev1990 has quit [Quit: Konversation terminated!]
<gudvinr>
Also chip-community is quite outdated source of information (though it has a great description of CHIP hardware) since inclusion of Alwinner bits in newer kernels/u-boot etc. And every link points to now nonexistent NTC repository