ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
<apritzel> MasterR3C0RD: thanks!
<apritzel> and is that really the same power rail? typically PortC and the PHY are on separate rails
tokyovigilante has quit [Remote host closed the connection]
tokyovigilante has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
<MasterR3C0RD> It seems like ALDO1 powers PortC and PortL at minimum; there is a separate rail supposedly for the PHY, but the Ethernet LED seems to be statically powered by something
<apritzel> can you dump /sys/kernel/debug/regulators/regulators_summary from the running vendor system?
<MasterR3C0RD> Will do in about 30m
<apritzel> that's in my experience the most reliable way to figure out the rail assignment
<MasterR3C0RD> I figured most of the critical ones out by killing regulators in U-Boot and seeing what results I got, then comparing ones that made the system hang to important voltages in the datasheet, while non-important ones I tried to see what broke
<MasterR3C0RD> ALDO1 on my board definitely controls PortL; if it's turned off I start getting garbage back from the regulator and can't turn it back on
<MasterR3C0RD> s/regulator/PMIC/
<apritzel> ah, very good! What is your PMIC? AXP803/707? Or something else?
<apritzel> for me PortL is ALDO3, apparently at 3.3V, and PortC is powered by ELDO1
<apritzel> and the tablet detected that I changed the boot partition with an image patched by Magisk, and refused to boot :-(
KREYREN_oftc has quit [Ping timeout: 480 seconds]
<MasterR3C0RD> apritzel: Bootloader bit's a frustrating point; sounds like they have it locked down quite hard. Usually you'd be able to "unlock the bootloader"; not sure if that's possible on your device though
<MasterR3C0RD> Also PMIC is AXP806, thus why I have the AXP305 SPL driver enabled for A133 on my branch
<apritzel> ah, right, I now remember. So that means different rails are used, which explains the differences between our devices in this regard
<MasterR3C0RD> Yeah, the rails are all a bit weird. Actually one of the weird bits is that in boot0, DCDCA is set in a "pll_set_voltage" routine, while in the device tree it's the CPU power supply
<MasterR3C0RD> Considering DVFS works the latter seems like the correct interpretation
<apritzel> I think it must be DCDCA, polyphased with DCDCB, there is virtually no other choice which satisfies the CPU's needs
<MasterR3C0RD> Well, if I disable DCDCB nothing changes
<MasterR3C0RD> When checking regulators, DCDCB is set to 1.8V, whereas DCDCA starts at 1.1V
<apritzel> please don't do this ;-) DCDCB is most likely "married" to DCDCA (polyphased), because one DCDC is not enough for all the cores
<apritzel> this is typically customised, we don't touch that setting, the Linux driver just reads it and skips DCDCB
<apritzel> check axp20x_is_polyphase_slave(), maybe put a printf in there to check that (or read 0x1b and see for yourself)
<MasterR3C0RD> Reading 0x1B returns 0
<apritzel> ah, interesting, then you indeed don't have a polyphase. Though that sounds sketchy, I'd think the A133 is in the same ballpark as the other quad-A53 SoCs when it comes to power consumption
<MasterR3C0RD> Well, it doesn't exactly appear this thing is the definition of "good design", so I'm not entirely surprised LOL
<MasterR3C0RD> This is what the PMIC registers look like when I just don't have regulators in my DTS
hipboi has joined #linux-sunxi
<MasterR3C0RD> It might also be related to this being an R818 and not an A133
<MasterR3C0RD> Perhaps they're mostly the same but are rated for different performance characteristics
<MasterR3C0RD> It's also a rebadge; Creality calls it a "T800"
<MasterR3C0RD> A Creality T800*
<MasterR3C0RD> Oh interesting! There were actually devices that used an A100. https://fcc.report/FCC-ID/2APD4-AP10/5210695.pdf page 2
hipboi has quit [Quit: hipboi]
apritzel has quit [Ping timeout: 480 seconds]
hipboi has joined #linux-sunxi
<MasterR3C0RD> parthiban: Thanks for the Tested-bys! If you get a chance, can you test gadgets again after disabling ohci0 and ehci0 in your device tree?
<MasterR3C0RD> Do so after switching back to an a33 compatible, of course
hentai has joined #linux-sunxi
<MoeIcenowy> MasterR3C0RD: Yangtao Li is Yangtao/Frank Lee
<MasterR3C0RD> MoeIcenowy: Cool, good to know! I was curious since I had him in my patch series CCs as a maintainer with his tiny.windzz email, while his allwinnertech email doesn't seem to exist anymore
JohnDoe_71Rus has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
hipboi has quit [Quit: hipboi]
parthiban has quit [Quit: Leaving]
parthiban has joined #linux-sunxi
<MasterR3C0RD> Neat; if SyterKit is to be believed, if we fix up base addresses and get a CCU config, the A133 DRAM driver should theoretically work on the A523/A527 and other sun55iw3 chips
parthiban has quit []
parthiban has joined #linux-sunxi
parthiban has quit [Remote host closed the connection]
parthiban has joined #linux-sunxi
<MasterR3C0RD> Actually it matches the H616 better with how the COM registers are used
<parthiban> MasterR3C0RD: Disabling hci in DT works.
<parthiban> Morning!
<parthiban> PHY was claimed by the HCI?
<MasterR3C0RD> Morning! Happy to hear it works
<MasterR3C0RD> That's what we believe yes; apparent the musb drivers can be a bit of a mess sometimes
<MasterR3C0RD> But that's not something to be fixed in this patch series; if it's working when the HCIs are disabled then it's working period, just means OTG won't work at the moment
<MasterR3C0RD> Apparently on most boards this isn't an issue because MUSB claims the PHY before HCI does, but sounds like it's running into a bit of a race condition
<parthiban> I have a complex hub in the PCB.
<parthiban> HUB facing the host side. UART0 and USB0 is connected from the SoC.
<MasterR3C0RD> In that case I presume you'll want to keep the HCI0 nodes disabled anyways then
<parthiban> Otherwise, mmc0 and mmc1 is the only part which I can't test yet in your series.
<MasterR3C0RD> I've confirmed HCI0 works on my board when in host mode. The MMC patches may get held back if things get applied from this series though; there's not much rationale for vs against the clock fix at the moment
hipboi has joined #linux-sunxi
<parthiban> eMMC works. You can atleast keep them?
<MasterR3C0RD> eMMC only works with the reparenting patch; I don't have enough time before the window of opportunity to get this in for 6.13 closes to figure out why the NO_REPARENT was set on the nodes to begin with (even though I've been spending a lot of time on this, it's all on the side and unrelated to my job)
<parthiban> MasterR3C0RD: eMMC works in my end without removing reparent
<parthiban> Not sure what's the difference between the hardware we have.
<parthiban> So I would like to keep the eMMC in the patch series
<parthiban> One other question, "reboot" command hangs too. Is this related to BL31 as well?
hipboi has quit [Quit: hipboi]
<MasterR3C0RD> I'm afraid I don't have time to resubmit and drop the reparenting patch, as my many extremely late nights lately are catching up to me. I would need to replace the MMC patch with a different one that only adds the eMMC node, and I'd need to resubmit the series. I don't think they'll accept the MMC patches if they aren't functioning without a
<MasterR3C0RD> dubious patch. However, the fact that eMMC worked correctly on your device but not mine seems interesting; hopefully we'll be able to track down the root cause for the next patch window.
<MasterR3C0RD> Also yes, reboot failing is due to BL31
<MasterR3C0RD> It throws a stack trace from TF-A when a reboot is attempted
<parthiban> MasterR3C0RD: Ok then. Did I miss anything else in the series to test?
<MasterR3C0RD> The PMU node is the only new node without known issues and without a tested-by
<MasterR3C0RD> I don't really know how that would be tested though, so I think we're probably good on testing
<parthiban> Great.
<parthiban> btw, did you had time to check the LPDDR4 in the u-boot? Let me know how can I help.
<MasterR3C0RD> I didn't yet get a chance to figure out why the Helperboard wasn't working if that's what you mean; I'm still thinking it's related to the RAM size/configuration, but I'll dig into it further in a few days
<parthiban> Helperboard comes with 1GB RAM, which works fine. That's how am able to test your series.
<MasterR3C0RD> Oh right it was your other board
<parthiban> I have a custom PCB with 4GB LPDDR4, which didn't work.
<MasterR3C0RD> I'm having a bit of code fatigue on the DRAM front, so I'm going to leave it sit for a few more days. In the meantime I plan to see if I can get more progress on bringing up more peripherals on my device
<MasterR3C0RD> Side note, looks like I shouldn't have much trouble getting UART on the TrimUI console: https://i.redd.it/ufq5a1f6xtxc1.jpeg
<MasterR3C0RD> Well, I'll have trouble soldering to those tiny pads, and it's right next to what looks like the eMMC
<MasterR3C0RD> But at least they were nice and silkscreened where they are
apritzel has joined #linux-sunxi
hipboi has joined #linux-sunxi
hipboi has quit [Quit: hipboi]
hipboi has joined #linux-sunxi
hipboi has quit []
warpme has joined #linux-sunxi
warpme has quit []
hipboi has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel has quit [Remote host closed the connection]
warpme has quit []
apritzel has joined #linux-sunxi
hipboi has quit [Quit: hipboi]
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
ungeskriptet has joined #linux-sunxi
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
Jookia has joined #linux-sunxi
hipboi has joined #linux-sunxi
warpme has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.4 Quasar http://www.kvirc.net/]
warpme has quit [Remote host closed the connection]
bauen1 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
Hypfer has quit [Quit: The Lounge - https://thelounge.github.io]
Hypfer has joined #linux-sunxi
<parthiban> "gpioget: unable to request lines: Unknown error 517" AFAIK, this is the main reason other problems when using pio. r_pio works fine.
<apritzel> parthiban: 517 is EPROBE_DEFER, which means there is some dependency missing for probing the driver, like a clock or a regulator
<apritzel> please note that you cannot announce the vcc-pl-supply in the DT, since that creates a circular dependency (PMIC is on R_I2C, R_I2C uses PortL pins, PMIC provides PortL power rail)
<apritzel> error -517 is not fatal, it's tried later again, and might have succeeded. Check in /sys/kernel/debug/devices_deferred, it should be empty
<apritzel> and ideally whatever outputs that error should be silenced because of this, in the kernel there are error wrappers that take care of that automatically
<apritzel> MasterR3C0RD: for testing the PMU: run some "perf record" command, and check that it works and the interrupt counter in /proc/interrupts increases
<apritzel> but we don't need Tested-by: for every patch, reviews or ACKs are more important. Tested-by: is also to give maintainers some clue who to ask when something needs testing in the future
warpme has quit []
warpme has joined #linux-sunxi
dsimic is now known as Guest8136
dsimic has joined #linux-sunxi
Guest8136 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<parthiban> PA bank doesn't exist, but the pinctrl considers this bank and 32 pins for it. I was assuming <&pio 0> -> refers to PB, which was wrong the whole time.
warpme has quit []
<apritzel> ah yes, the offsets are (<letter> - 'A') * 32 for PIO, and (<letter> - 'L') * 32 of R_PIO, refer to: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c#n82
<apritzel> (for the normal PIO driver it's not explicitly listed, as it's 0)
warpme has joined #linux-sunxi
Jookia has left #linux-sunxi [#linux-sunxi]
hipboi has quit [Quit: hipboi]
<parthiban> ok. gpioget works, but gpioset hangs. not sure why.
<parthiban> Tried testing that with GPIO connected LED. Setting the trigger from dts works, but gpioset isn't.
<MasterR3C0RD> parthiban: Is the hang a hard hang, or can you Ctrl-C out of it?
<parthiban> I can exit with ctrl + C
<MasterR3C0RD> Anything in dmesg when it happens?
<parthiban> No
warpme has quit []
<MasterR3C0RD> If you `cat /sys/kernel/debug/pinctrl/*/pinmux-pins`, do you get anything?
<parthiban> Yes, no problem in reading
<MasterR3C0RD> What's the function set for the pin you're trying to use?
<parthiban> Connected to LCD enable. Normal GPIO output active high.
<parthiban> pin 38 (PB6): GPIO 300b000.pinctrl:38
<parthiban> gpiochip2 38 unnamed output consumer=enable
<parthiban> So the pin is claimed when I use with pwm-backlight. But unable to control.
<parthiban> Doesn't need to complicate with PWM though. I have a LED in the PCB. Which I couldn't turn on using "gpioset"
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #linux-sunxi
<MasterR3C0RD> If you compile U-Boot with the gpio command, does it work there?
<MasterR3C0RD> Can't test on my device right now, but I know that basic GPIO should work correctly
<MasterR3C0RD> I was able to turn on/off PH19 without any issue, and created an LED device for it in my device tree that I was also able to turn on, off, and assign to a trigger
<parthiban> It works from devicetree if claimed by the Kernel.
<parthiban> but not from the userspace using gpioset
<parthiban> MasterR3C0RD: from u-boot it works
<MasterR3C0RD> No clue what could be the issue then I'm afraid, it could be an issue with libgpiod or something
<parthiban> I can live with claiming in the kernel from dts for now
KREYREN_oftc has joined #linux-sunxi
flyback has quit [Ping timeout: 480 seconds]
flyback has joined #linux-sunxi
KREYREN_oftc has quit [Ping timeout: 480 seconds]
ity1 has joined #linux-sunxi
ity has quit [Remote host closed the connection]
ity1 has quit []
ity has joined #linux-sunxi
vagrantc has joined #linux-sunxi
bauen1 has joined #linux-sunxi
<parthiban> "armv8-pmu pmu: probe with driver armv8-pmu failed with error -22"
<parthiban> "armv8-pmu pmu: hw perfevents: failed to parse interrupt-affinity[1]
<parthiban> this means PMU is not loaded?
<parthiban> not sure if this is because I commented the secondary CPU's
<apritzel> did you change the PMU node accordingly, since it references the CPUs?
digetx is now known as Guest8150
apritzel has quit [Ping timeout: 480 seconds]
digetx has joined #linux-sunxi
Guest8150 has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
<MasterR3C0RD> parthiban: Instead of commenting out the additional CPUs, it might make more sense to add "nosmp" to your kernel command line
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.4 Quasar http://www.kvirc.net/]
apritzel has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
bauen1 has quit [Quit: Lost terminal]
parthiban has quit [Remote host closed the connection]
dliviu has quit [Ping timeout: 480 seconds]
parthiban has joined #linux-sunxi
dliviu has joined #linux-sunxi
<MasterR3C0RD> Randomly thinking about the A133 DRAM code, and realized one thing is less of a mystery than I thought; there's 3 additional sets of "shadow registers" in the uMCTL2 DRAM register block, which normally have the same values being written to as those on the main registers, but I wasn't sure why. However, I think it's likely for configuring settings
<MasterR3C0RD> specific to different DFS (Dynamic Frequency Scaling) modes. Not exactly critical functionality, but it would explain what they're being used for
<apritzel> so you mean there is a register which selects one of those banks then?