Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<wens>
apritzel: (reading logs) the entry for the display engine in DT is the display-engine node. This sits outside of the OF graph but points to phandles for the beginning of all pipelines
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
<wens>
oh I see you already figured it out
gsz has joined #linux-sunxi
<Jookia>
uh-oh. i found a bug in my panel code that can't be easily fixed in u-boot :\
<Jookia>
the nv3052c code requires setting a register based on bit depth or the screen is dim, but u-boot has no mechanism of doing thing
<Jookia>
maybe using the bus format is the right way...
<Jookia>
i'll have to think about this.
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
<loki666>
tokyovigilante: did you tried my build ?
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<tokyovigilante>
loki666: not yet sorry, have been working on the u-boot display code
<tokyovigilante>
Jookia: have got the power supply sorted and got the backlight on in u-boot, but seeing this now: nv3052c_panel panel@0: pinctrl_select_state_full: pinctrl_config_one: err=-38
<tokyovigilante>
must be getting close..
<tokyovigilante>
video 0 [ + ] sunxi_de2 |-- sunxi_de2
<loki666>
ok let know, how it goes, because I fear we are pushing dvfs for 6.11 that will need a hotfix
<loki666>
if you have a stable Kconfig for your h700-cpufreq-fix branch, I can give it a shot, but I don't think it's related to kconfig choices, either dvfs is enabled or it is not
<loki666>
the issue is scaling_gov, as soon as I set your alpine build to schedutil
<loki666>
it crash
NishanthMenon has quit [Ping timeout: 480 seconds]
<tokyovigilante>
Is there any reason to change it?
<loki666>
no, it was just set by default by arm64 defconfig, and seems to be the new recommended scaling gov
<loki666>
but the real question, is why does it crash
bauen1 has joined #linux-sunxi
<tokyovigilante>
I would suggest defaulting to conservative, which will still scale to 1.5GHz as required
<loki666>
sure, but this is more like a workaround
<tokyovigilante>
mine defaults to conservative, I don't think I ever changed it. Buildroot may default to schedutil I suppose
<tokyovigilante>
Would be worth feeding that back on the list, but I feel like that's more of a thing to document rather than a reason to revert or not have the 1.5GHz OPP available. The bug may be in the schedutil governor, or a combination of the two
narmstrong has joined #linux-sunxi
<loki666>
now that we have a lead, i'll test the other governors
benettig has joined #linux-sunxi
lvrp16_ has joined #linux-sunxi
NishanthMenon has joined #linux-sunxi
<tokyovigilante>
thanks, that's good detective work
arnd has joined #linux-sunxi
yang has joined #linux-sunxi
<loki666>
I can't hack the kernel, but I can a least test it
<tokyovigilante>
it's only a small step from there to here ;)
yang is now known as Guest10736
palmer has joined #linux-sunxi
<tokyovigilante>
Do you see instability with schedutil + the 6.9 DVFS code? ie just the lower frequencies?
<loki666>
it was stableis when I removed latestes 2 freq bins
<tokyovigilante>
ok, good to know
<loki666>
I think 6.9 didn't work at all, it was missing the hw-support in the DTS
<loki666>
and the code patch you made
<tokyovigilante>
Ah sorry, yeah 6.10. I've been running too many patches on top
<tokyovigilante>
interestingly the vendor BSP runs schedutil with the 1.5GHz bin and seems fine
<tokyovigilante>
on a much older kernel of course
<tokyovigilante>
I would definitely feed it back to the list
<loki666>
oh, I thought shedutil didn't exists yet on 6.4
<loki666>
it using ondemand
<tokyovigilante>
that's according to my CFW, I'll dig into it
Guest10736 is now known as yang
<loki666>
looks like on schedutil is causing issues, conservative, ondemand, powersave and performance are working fine
<loki666>
didn't test userspace
<apritzel>
loki666: that's good info for the list!
<apritzel>
yeah, for example. Most important is to include the right people, tokyovigilante's series should have them already
bauen1 has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
<wens>
IIRC from issues at work, schedutil requires two passive trip points
bauen1 has joined #linux-sunxi
JohnDoe3 has joined #linux-sunxi
<Jookia>
tokyovigilante: not sure what the pinctrl thing is
dsimic is now known as Guest10751
dsimic has joined #linux-sunxi
Guest10751 has quit [Ping timeout: 480 seconds]
<Jookia>
tokyovigilante: could you tell me if the rg35xxx has a nice pmic with proper reset? as in the rails go down them up on reboot?
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
electricworry has joined #linux-sunxi
Gabriel has joined #linux-sunxi
Gabriel has quit [Remote host closed the connection]
Gabriel has joined #linux-sunxi
Gabriel has quit [Remote host closed the connection]
haluka has joined #linux-sunxi
warpme has quit []
haluka has quit [Remote host closed the connection]
<apritzel>
Jookia: IIRC the AXP717 has reset functionality, though we don't use that atm
<apritzel>
reboot goes via PSCI, though, so we could change TF-A to use the PMIC for reboot, instead of the watchdog
<Jookia>
i've found that these panels need proper power cycling if uncleanly reset :\
<Jookia>
i'm going to try troubleshooting the reset logic a bit more
<Jookia>
otherwise the panel introduces artifacts such as flickering or lack of channels
<apritzel>
yeah, that's an interesting problem: the normal Linux reboot only affects the SoC, not anything on the board (or beyond)
<apritzel>
Jookia: is that for some T113-s3 board? Those typically don't have a PMIC, do they?
<Jookia>
yeah. so i was wondering if the rg35xx pmic resets the LCD
<Jookia>
things like that
<Jookia>
it could also be that this is specific to the panel i have
<apritzel>
is there some extra pin on the panel to reset it, maybe?
<Jookia>
yes, there's a reset gpio and reset instructions that does reset it. but something is not getting reset. so i'll have to experiment
warpme has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has quit []
<macromorgan>
Jooka: Hold the panel in reset in your panel disable/unprepare routine?
<macromorgan>
I think I do that on every panel driver I've done thus far since issues like to pop up
<macromorgan>
also, starting over and narrowing things down, it looks like the i2c_write() is what's failing when dcdc2 and dcdc3 get set on boot for the AXP717 in U-Boot SPL
<macromorgan>
digging into that a bit more
<macromorgan>
looks like i2c_write is writing the value but not receiving an acknowledgement
<loki666>
wens: what do you mean?
JohnDoe3 has quit []
warpme has joined #linux-sunxi
gsz has joined #linux-sunxi
warpme has quit []
Schimsalabim has quit [Read error: Connection reset by peer]
apritzel has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
ftg has joined #linux-sunxi
vagrantc has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
electricworry has quit [Quit: Leaving]
vagrantc has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]