<junari>
There should be a patch for LPDDR4 somewhere in armbian
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Techflash has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
junari has quit [Remote host closed the connection]
<wens>
apritzel: I don't like the pinmux method, as it doesn't allow specifying pins without mux (for example in case you want to set drive strength on a GPIO line connected to an LED)
apritzel has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
vpeter has quit [Remote host closed the connection]
dsimic is now known as Guest6438
dsimic has joined #linux-sunxi
Guest6438 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<apritzel>
wens: ah, you mentioned that before, but I didn't get it first: is that because we don't have pinctrl groups for GPIOs, instead the devices are requesting the GPIO-IN/OUT functions? Say an LED device?
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
<wens>
correct. Don't remember which SoC exactly, but we started to enforce _no pinmux_ for GPIO usage
<apritzel>
I see, so the pinctrl node would then just contain the "pins" and the "drive-strength" property, but no "function"?
<wens>
that's the idea, though to be honest I've never actually tried it
megi has quit [Quit: WeeChat 4.4.4]
megi has joined #linux-sunxi
<apritzel>
I wonder if that "pinmux" property would be a deal breaker in this case, though: you could still specify the mux value of 1 for gpio_out, right? As long as no one refers to that via pinctrl-0, that should be fine?
JohnDoe_71Rus has joined #linux-sunxi
<wens>
if no one refers to it, the pin config doesn't get set either
<apritzel>
right, but how do you refer to that node then? If you use a *-gpios property, that would race with any pinctrl-0 property, right? Do you have an example?
<wens>
you use the pinctrl-0 property, just not with a pinmux / function specified in the referenced node
<wens>
apritzel: in the kernel the pinctrl is set before the probe function is called, there's no race.
<apritzel>
I mean if someone else refers to that GPIO via some *-gpios property (say an LED), that this would appear as already taken, by the pinctrl?
szemzoa has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<MasterR3C0RD>
A5E arrived on my doorstep earlier, hopefully will have some time to take a look at booting it up tonight
<apritzel>
loki666: not sure you have seen, but your IRQCHIP_SKIP_SET_WAKE patch already made it into mainline, actually still in the 6.13 release
<apritzel>
which is a bit scary, I would we would have had a bit more testing time. But it seems to work, even without wakeup-source (?)
<apritzel>
but my revert of the "dual PMIC support" patch didn't make it, so v6.13 is now broken for devices with chargers, I believe :-(
jkm has quit [Quit: Lost terminal]
<apritzel>
MasterR3C0RD: welcome to the club! I will see if I can push my U-Boot WIP branch later
<MasterR3C0RD>
apritzel: What RAM configuration did you get, just curious?
<apritzel>
4GB of course ;-)
<loki666>
apritzel: I was, I think the wakeup-source is needed, but I hold it off, since I though it's more board specific and not soc
<loki666>
crap for the dual PMIC, I'll revert it for our project
<apritzel>
MasterR3C0RD: the latest theory is that the DRAM init is not fully working for the A5E, although it seems to be working fine to the X96QPro+ and the Avaota
<loki666>
but I was also surprise that it was applied without any feedback on it
<apritzel>
MasterR3C0RD: I use the same DRAM code as on jernej's github, so you can use that meanwhile, as a base
<apritzel>
loki666: seems to work for me without wakeup-source, on that H728(A523) TV box
<loki666>
ah, I'll try without it...
<loki666>
any feedback on my OTG patch, hopefully I marked it as RFC because it doesnt compile... (I already have the fix)
<apritzel>
I will have a look, but it requires quite some context switch, so maybe later this week
<MasterR3C0RD>
apritzel: I'll give jernej's code a look later then and see if I can catch anything
<loki666>
no problem, did the cpu reparenting did make it to 6.13?