00:18 <tokyovigilante> awesome, thanks

00:35 <Jookia> tokyovigilante: the cover letter isn't being reviewed :)

02:23 <KREYREN_oftc> What's A64-H? I just noticed that it's on my OlinuXino-A64

02:23 <KREYREN_oftc> but teres has A64 without H

02:26 <Jookia> new A64 dropped?

02:26 <KREYREN_oftc> Jookia, i got the olinuxino board with teres so kinda like 1 year now?

02:27 <Jookia> maybe ask olimex

02:27 <KREYREN_oftc> Jookia, he's avoiding me i ask too many questions

02:28 <KREYREN_oftc> and mocking him for teres CPUs

02:28 <KREYREN_oftc> .. for the mad man to release MIPS board

02:28 <Jookia> yeah if you mock someone they won't reply to you

02:30 <KREYREN_oftc> it's supportive motivation rather than mocking but he mostly doesn't talk with me bcs i have too many teres questions

02:30 <KREYREN_oftc> though i have a method to make him merge my things https://github.com/OLIMEX/DIY-LAPTOP/pull/69#issuecomment-1998637273

02:30 <KREYREN_oftc> 50% success rate so far

02:52 <KREYREN_oftc> it seem that A64-H is a version designed for industrial use, appears to be the same chip just different housing for it?

04:28 <gamiee> KREYREN_oftc: A64-H is same chip as A64, -H means HDMI. It's some weird deal with HDMI company and Allwinner.

06:55 <KREYREN_oftc> gamiee, is the A64 without the -H not working well with HDMI?

07:02 <gamiee> KREYREN_oftc : no, it works absolutely fine. It's just new batch of A64's with -H postfix, but same stuff as far as I remember.

07:33 <KREYREN_oftc> gamiee, i see O.o

07:42 <Jookia> it.s the h series, buy more :)

08:44 <buZz> HA64? :D sounds nice

09:00 <Jookia> H64-A

09:38 <tokyovigilante> macromorgan_: I'm not seeing any instability allowing ALDO1 a range of 1.8-3.3v, but then SD2 fails to work

09:38 <tokyovigilante> which doesn't quite make sense given the vendor BSP allows 0.5-3.5v, but *shrug*

09:56 <tokyovigilante> actually, SD2 fails to work unless I define a fixed vcc_3v3_sd2 regulator, but not even using it for vmmc (using CLDO4 as in my v3 patches). Must be something to do with the GPIO regulator, but it's in the too hard basket for tonight

10:09 <apritzel> tokyovigilante: see my reply to macromorgan_'s mail ...

10:35 <tokyovigilante> was just reading that, ta. I'm inferring the regulator itself is a red herring and there's another way to describe that level-shift GPIO?

10:37 <apritzel> my hunch is that it's really the two regulators and a switch. Just not sure if that switch is before VCC-PC (easier), or just covering the PC SD pins

10:39 <tokyovigilante> ok, cool. acceptable to leave that extra regulator in then?

10:40 <apritzel> there is gpio-regulator.yaml which can describe such a circuit, check sun50i-h5-emlid-neutis-n5-devboard.dts for an example

10:40 <tokyovigilante> ta, will do. this was the only thing i couldnt figure out blocking a v4

10:40 <apritzel> but I am tempted to not introduce that at this stage, but instead just go with one 3.3V for now

10:43 <tokyovigilante> i'm cetainly happy if it just works, long term will be nice to get UHS speeds

10:44 <apritzel> certainly, but we should be fairly confident how it works then

10:44 <apritzel> and it would actually be the first Allwinner board utilising UHS speeds in mainline, AFAIK

10:45 <apritzel> because this supply switching hasn't been done before, and it's a bit tricky to do on SDC0. The H616 actually introduced some internal muxer, though we don't support this yet

10:46 <apritzel> and it's rare that people put a second SD card on a board. Also changing the whole VCC-PC supply basically sacrifices the whole PortC for being used for anything else

10:48 <apritzel> unless that can cope with suddenly being switched between 1.8V and 3.3V I/O levels, which might be OK for switches, but would certainly not be easy for LEDs, for instance, or other chips

10:49 <tokyovigilante> that was one of the draws of tbe device, other handheld/portables like the uconsole or even the rPi make you choose eMMC or SD, not both. but all the Anbernic devices seem to have two slots.

10:50 <tokyovigilante> to be fair the regulator-gpio doesnt look too bad, presumably only two levels and we already know tbe right pin, so able to brute-force it (my usual dev method)

10:51 <apritzel> problems seems to be that regulator-gpio somewhat seems to take those voltage supplies "out of thin air"

10:51 <apritzel> what we actually want is a muxer: two supply voltages, and one GPIO to toggle the output between the two

10:51 <apritzel> I couldn't find such a thing yet

10:52 <apritzel> that's why I think it's best to hold back with that idea for now, to not jeopardise the whole DT being merged

10:53 <apritzel> jernej_ will probably send the PR tomorrow evening (GMTish time zome), that sounds a bit of a close call for experiments

10:53 <tokyovigilante> sure. ok will leave as is for now, but that extra vcc-3v3-sd2 seems to be required regardless, so will leave as is for now

10:54 <tokyovigilante> does jernej_ have a muxer patch or are you meaning the DT v4?

10:55 <apritzel> I meant the deadline for v6.10 inclusion is probs tomorrow, when jernej_ sends the sunxi PR up the chain

10:56 <tokyovigilante> ah right, will keep it simple then

10:56 <tokyovigilante> thanks again for all the help, been a wild ride and learning experience

10:57 <apritzel> np, glad it worked out so well