<Galland>
I saw on p.2 there are two other push buttons:
<Galland>
SW1 for PMIC_PWRON (which is connected just to the ACT8846 PMU chip) and POWER_SW (only to exp. header)
<Galland>
and another pushbutton (SW2) for PWR_EN (that also goes to the exp. header) that connects too to the PMU chip
Guest18545 has quit [Ping timeout: 260 seconds]
<Galland>
and bifurcates to a PWR_HOLD label
<Galland>
after some discrete components does go to RK3188 GPIO_A0 at pin AC4
<Galland>
this SW2 is labelled RESET, so...
<Galland>
could be used as resume-from-suspend IF the low pulse (when pushing SW2) doesn't make the PMU reset (to whose PWR_EN pin it's connected)
<AstralixNB>
afaik you can software-configure the power buttons on the PMIC and you can read their status out via I2C
<AstralixNB>
so a comfortable power system should be possible, including soft off and push-button power on
Galland has quit [Read error: No route to host]
Galland has joined #linux-rockchip
<Galland>
PMU's datasheet says about PWREN: "Drive PWREN to a logic low to turn off the REG3."
<Galland>
now, what's REG3... reading
<Galland>
hmmmmm error
<AstralixNB>
REG3 is normally regulator 3
<Galland>
pushbutton SW2 (labelled RST) is connected to a label called "PWR_EN"
<AstralixNB>
so ahould be DC3
<Galland>
which is in turn connected to PMU's pin PWRHOLD
<Galland>
whereas PMU's pin PWREN is tied to vcc_io
<Galland>
:S
<AstralixNB>
AFAIR PWREN to vcc_io was correct...
<Galland>
ACT8846 datasheet on PWRHOLD: "Power Hold Input, enable input for REG1, REG2, REG4, REG5, REG6, REG8 and REG10. PWRHLD is internally pulled down to GA through a 900kΩ resistor."
<Galland>
(btw REG3 is connected to VDD_ARM)
<AstralixNB>
Yes, tying it to REG3 gives power-sequencing
<AstralixNB>
or the other way round
<AstralixNB>
Power Enable Input for REG3. PWREN is functional only when PWRHLD is driven
<AstralixNB>
high. Drive PWREN to a logic high to turn on the REG3. Drive PWREN to a logic low
<AstralixNB>
to turn off the REG3.
<Galland>
sure sure, I'm not judging the circuit, just trying to see if that pushbutton can be used for resume-from-suspend
<AstralixNB>
ah, suspend in means of waking up from active DRAM controller, refreshing?
<Galland>
but it doesn't seem to be the case, since SW1 is connected only to the PMU chip (ACT8846) and it's clearly the power button
<Galland>
and SW2 is connected to PMU and RK3188, but pushing it makes the PMU reset the power
<Galland>
so my bet on SW3 (labelled RECOVERY) continues to be on :)
<Galland>
yes, Astralix
<Galland>
I was thinking of a suspend to ram where the wake up source is a pushbutton
<Galland>
I think that could be interesting to have an instant-on
<Galland>
if these chips consume so extremely few while on... how much less could they consume while suspended? :D
<AstralixNB>
But there is a button on PBIN ... SW1
<AstralixNB>
an the PWR_KEY signal follows PBIN
<AstralixNB>
check the GPIO for PWR_KEY and you're done
<AstralixNB>
PWR_KEY is on GPIO0_A3
<AstralixNB>
no, A4
<AstralixNB>
So pressing it while OFF will start DC/DC, pressing it while ON will raise an IRQ or polled event for waking things up.
<Galland>
hmmmm
<Galland>
SW1 is connected to label POWER_SW that only goes to the expansion header
<Galland>
and to label PMIC_PWRON that only goes to the PMU
<Galland>
I can't see the connection to RK3188's GPIO :S
<Galland>
where is it?
<AstralixNB>
My SW1 has PMIC_PWRON via 51k resistor from POWER_SW
<Galland>
yes, and PMIC_PWRON goes to the PMU
<AstralixNB>
and PMIC_PWRON is landing at pin 31 of ACT
<Galland>
is there any way out of there?
<AstralixNB>
And in PMIC datasheet it says nPBSTAT is following nPBIN
<Galland>
that's cool, I see now, the pin below PMIC_PWRON
<AstralixNB>
yes
<Galland>
and in the datasheet, nPBSTAT is: "Active-Low Open-Drain Push-Button Status Output. nPBSTAT is asserted low whenever the nPBIN is pushed, and is high-Z otherwise."
<AstralixNB>
yes
<Galland>
(I am copy-pasting for reference for others to follow :D )
<AstralixNB>
You find it on ACT8846 datasheet, pin table on page 6
<Galland>
and so, as you said, nPBSTAT is connected to label PWR_KEY that lands on GPIO0_A4 (pin AA6)
<Galland>
directly, so we should activate that GPIO's pullup in software
<AstralixNB>
to be honest, I verified this part of the schematics long be fore the name of the board was found.
<arokux>
guys, have you given you ship addresses to hipboi already?
<Galland>
me, yes
<arokux>
Galland, were you asked by hipboi?
<arokux>
AstralixNB, what about you?
<arokux>
I'm just trying to figure out if I missed something...
<AstralixNB>
You cannot ask me for the normal delivery line... I am not a good example for it, I guess. Just way a few days and give hipboi a chance to establish payment and delivery setup.
<arokux>
thanks AstralixNB
<Galland>
Astralix, I'm not sure about using the nPBIN, since its description says: "drive nPBIN directly to GA to assert a Manual-Reset condition."
<Galland>
so pushing the button while the system is powered (on suspend in this case) will cause a reset :S
<Galland>
I'm reading what "Manual-Reset" means on p.29 of the datasheet
<Galland>
taking into account that the schematic does contain a 51K resistor
akaizen_ has joined #linux-rockchip
<Galland>
and looking at fig.29, then that pushbutton may indeed not cause that reset
<Galland>
fig.2
akaizen has quit [Ping timeout: 240 seconds]
<Galland>
ok, p.30 seems to clarify this, when using the 50K r then the nPBIN enables/disables system
<Galland>
that is power on
<Galland>
and: "a typical disable sequence is initiated when the user presses the push-button, which interrupts the processor via the nPBSTAT output. After system is turned on, the processor may shut down the system by setting OFFSYSCLR[ ] to 1 then setting OFFSYS[ ] to 1, or by pulling PWRHLD to logic low."
<Galland>
so the system disable is not automatic, but CPU initiated, so indeed that pushbutton may be used for anything
<Galland>
wow, you are the one behinf sunxi fb driver?
<Galland>
Siam...
<Galland>
?
<ssvb>
yeah, some people posted some links about radxa board in #linux-sunxi :)
<Galland>
yes, indeed I was planned to look there and in the partial implementation that olegk0 did for a RK Fb driver, that included RGA and IPP (another 2D HW accelerator for RK)
<Galland>
then, I hope you guys like the radxa board so much so as to switch over to RK development :-)
<ssvb>
looks like a fork of my early prototype code :)
<Galland>
in the end we can mostly follow sunxi's steps, specially regarding Mali, since it's the same 3D HW IP core inside RK chips too
<Galland>
yes, olegk0 mentioned it was based on yours :)
<Galland>
that's how I got to your blog, very interesting btw
<Galland>
I commented on your github repo, but just in case I'll repeat here: I'm currently using my rk3188 stick now with your xf86 sunxi fb driver
<Galland>
taking advantage of just NEON, and perfectly working
<ssvb>
good
<ssvb>
but it looks like you don't seem to have mali kernel modules there?
<Galland>
not on rk3188 yet, omegamoon working on that front
<Galland>
I got mali working on rk3066 following olegk0's footsteps
<Galland>
but not anymore on the 3188 (though it should be trivial since the Mali hw is the same)
<Galland>
I'm personally much more interested on having RGA work (hate to not be able to see movies at full screen :D )
<ssvb>
the most difficult part with mali is properly enabling mali clock and configuring the resources correctly (like irq numbers, etc.)
<Galland>
that must be the problem then, the intersection between the mali config/kernel source that did work with rk3066
<Galland>
and the new rk3188 cpu core (irqs/clocking/...)
<Galland>
btw, I'd like to ask you about a screen problem I'm seeing on Linux
<Galland>
every now and then (like once every hour) my screen goes black for a fraction of a second
<ssvb>
on an idle system? or when you are doing something with it?
<Galland>
it happened more often when I had a lower DDR freq, so at 1st I thought it could be that there was not enough DDR bandwidth for video memory
<Galland>
I got it to happen several times when opening a large zip file
<Galland>
that made suspect of the DDR
<Galland>
but then two days ago I ran your tiny memory testing tool (from your github)
<Galland>
and didn't get it to happen again
<Galland>
does this sound familiar to you?
<jpsminix>
Galland: What speed do you have on DDR?
<Galland>
500 MHz right now
<Galland>
and black screen happens once every hour or so
<Galland>
when I had it at 400 MHz it seemed to happen like once every 10 minutes
<ssvb>
1080p screen resolution?
<Galland>
yes
<jpsminix>
Could you up DDR to 600?
<Galland>
16 bpp
<jpsminix>
In my minix X5, i have 600, and i will try up to 666
<jpsminix>
660, sry
<Galland>
it's a .config option, jpsminix
<Galland>
CONFIG_DDR_FREQ or something like that
<jpsminix>
oh, well, yep, but my sources didnt have code to up more than 400
<Galland>
if that doesnt work even though your memory chips support it, then voltages must be changed too
<Galland>
neither did mine, but that's for changing voltage along with frequency (dvfs)
arokux2 has joined #linux-rockchip
<Galland>
for higher freqs it just keeps the highest voltage setting
<Galland>
ssvb: btw, using your https://github.com/ssvb/tinymembench on the rk3188 the tests seemed to be cpu-limited since I got 25% CPU usage while running them (1 core fully used)
<Galland>
should these tests be memory limited to make sure the cpu is not in the way of measurements?
<ssvb>
well, it is using a single CPU core, that's usually enough
<ssvb>
and it is more like a diagnostic tool for spotting oddities than a "benchmark"
<Galland>
I actually was using it to force a repeatable scenario for the screen blank issue
<Galland>
and also to demonstrate how NEON helped there :D
<ssvb>
then this problem indeed seems to be caused by some sort of memory misconfiguration
<Galland>
I'm confirming it, I've compiled the tool with -O2, it's right now testing and one cpu is fully used by the tool
<Galland>
continuously
<Galland>
misconfiguration in what sense/place?
<Galland>
btw, excuse me if this is explained somewhere I didn't see, but what does the percentage in parenthesis on the results mean?
<Galland>
C copy backwards : 362.0 MB/s (5.5%)
<Galland>
C copy : 626.6 MB/s (9.8%)
<ssvb>
misconfiguration in the sense that maybe there are some wrong priorities for accessing memory from the display controller and the CPU, ridiculously low bus clock speeds somewhere on the path to memory, etc.
<Galland>
I believe we're working with the stock bus speeds for internal AHB/AXI buses
<Galland>
what about the priorities? where would I be able to look those up?
<ssvb>
don't know, there could be some sort of a configuration register for this stuff
<ssvb>
the percents in brackets for tinymembench are showing sample standard deviation (if you have more than 1% there, then the system is probably not idle and something else is interfering)
<Galland>
or the cpu is at 100%?
<ssvb>
for example, there used to be an insane irq spam from usb on Raspberry Pi
<Galland>
that's true
<Galland>
I could into that, we have on the RK cpus the same DWC usb IP cores
<Galland>
so we share much of their problems there
<ssvb>
the CPU at 100% is not a problem, it's expected to be this way
<hramrach>
cpu waiting for memory fetch shows as busy
<Galland>
ok, good to know that then
<Galland>
I thought the results would be cpu limited instead of mem speed limited
<Galland>
now I see it's fine
<hramrach>
you cannot tell from the 100% load
<Galland>
btw nice to chat with you hramrach, between you and I we've edited half the linux-rockchip Wiki XDDD
<hramrach>
it's sad that we have few contributors
<hramrach>
I don't even have any actual rk hardware
<Galland>
well, things warm up slowly, but do warm up :)
<hramrach>
and the way some devs look at wiki pages is also fun
<Galland>
lol, I think I know what you mean
<Galland>
XDDD
<Galland>
they were born with everything already in their head XDDDD
<ssvb>
Galland: could you you try running tinymembench when the system is really not doing anything else, for example by replacing /sbin/init with shell and running the benchmark from there?
<Galland>
talking about the interrupts, just did: cat /proc/interrupts