leowt changed the topic of #linux-rockchip to: Rockchip development discussion | http://linux-rockchip.info | http://irclog.whitequark.org/linux-rockchip
Galland has quit [Quit: Saliendo]
tonikasch has quit [Quit: Bye!]
vinifr has quit [Quit: Saindo]
akaizen has quit [Remote host closed the connection]
naobsd has quit [Quit: Page closed]
naobsd has joined #linux-rockchip
Astralix has joined #linux-rockchip
Astralix1 has quit [Ping timeout: 264 seconds]
atiti has quit [Ping timeout: 264 seconds]
mmind00 has joined #linux-rockchip
eval- has quit [Ping timeout: 276 seconds]
atiti has joined #linux-rockchip
hipboi has joined #linux-rockchip
Theueip has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
eval- has joined #linux-rockchip
rellla has joined #linux-rockchip
akaizen has joined #linux-rockchip
AstralixNB has quit [Ping timeout: 264 seconds]
atiti has quit [Ping timeout: 245 seconds]
jpsminix has quit [Quit: leaving]
AstralixNB has joined #linux-rockchip
jpsminix has joined #linux-rockchip
jpsminix has quit [Quit: leaving]
jpsminix has joined #linux-rockchip
mcbrick has quit [Quit: Leaving]
Tsvetan has joined #linux-rockchip
tonikasch has joined #linux-rockchip
Theueip has quit [Quit: Leaving...]
AstralixNB has quit [Read error: Connection reset by peer]
AstralixNB has joined #linux-rockchip
AstralixNB has left #linux-rockchip [#linux-rockchip]
AstralixNB has joined #linux-rockchip
eebrah has quit [Read error: Operation timed out]
tinti has joined #linux-rockchip
AstralixNB has quit [Ping timeout: 264 seconds]
AstralixNB has joined #linux-rockchip
AstralixNB has quit [Quit: Leaving.]
eebrah has joined #linux-rockchip
eebrah is now known as Guest18545
Theueip has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
tonikasch has quit [Quit: Bye!]
Galland has joined #linux-rockchip
<Galland> hi
<jpsminix> hi
<AstralixNB> hi
<hipboi> hi
<mrueg> hi
<hipboi> Galland, we can talk about radxa rock board here
<Galland> fine, just wanted to make sure :)
<Galland> I'm really looking forward to it, after going over the schematic
<Galland> was talking yesterday with other devs. that there is this "Recovery" pushbutton
<Galland> tied to a RK3188 gpio
<Galland> that looks perfect to be used as a "Resume from Suspend" button if associated to the right irq
<Galland> on Linux, that is
<hipboi> i just made the list for the shipping
<hipboi> the engineer samples should be sent tomorrow
<Galland> oh, that's cool
<hipboi> there is also a power button
<hipboi> sorry, need to now
<hipboi> catch the bus home
hipboi has quit [Quit: Leaving]
<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
eebrah has joined #linux-rockchip
eebrah is now known as Guest40467
rellla has quit [Quit: Nettalk6 - www.ntalk.de]
Guest40467 is now known as ibrah
ibrah is now known as eebrah
ssvb has joined #linux-rockchip
AstralixNB has quit [Ping timeout: 264 seconds]
mmind00 has quit [Ping timeout: 245 seconds]
libv has joined #linux-rockchip
<Galland> welcome here libv
<Galland> the lima creator, I suppose
<libv> yes
<libv> found this via the radxa stuff
<Galland> yesterday I was asked about your: https://github.com/libv/mali-libs
<Galland> may I ask if those are your stuff or arm's¿
<Galland> ?
<libv> it all seems pretty early days for linux-rockchip, and much of it seems along the same lines as sunxi
<libv> Galland: that should not be used
<libv> use the sunxi-mali repository
<libv> it's the arm binaries provided by the cubieboard people
<Galland> great, I'll relay that info :)
<Galland> I've recently compiled the sunxi fb driver for RK
<libv> what mali kernels are currently available for rockchip devices?
<Galland> though RK chips don't have the 2D unit that Allwinner uses
<libv> Galland: you mean the xf86-video driver
<Galland> yes
<Galland> 2D
<libv> that would be display, as you yourself said that 2d support was lacking
<libv> which is also not true
<Galland> it takes advantage of NEON
<libv> X, with some basic FB and ssvbs neon stuff for speeding up 2d a bit
<Galland> but naturally doesnt find the 2D unit from allwinner
<Galland> RK uses another one by the name RGA
<libv> Galland: are there linux binaries (as in, not-android) available for rockchip devices?
<libv> or is that just sunxi-mali that everyone uses
<Galland> a developer by the nick olegk0 was succesful on getting mali from source for rk3066 devices
<Galland> but he disappeared from the scene
<libv> from source means: kernel side
<Galland> that is: no binaries, everything compiled from source, kernel, yes
<libv> i am specifically asking about userspace binaries
<libv> companies like radxa might be making them available under different terms than hardkernel does
<Galland> I asked Cubie about his releasing some sw, be it source or any other thing
<Galland> but still no response
<libv> which means that we might be able to integrate those into sunxi-mali and make even more kernel sides happy
<libv> is tom cubie working on rockchip stuff?
<libv> i thought that he was full on allwinner a20
<Galland> radxa board is his child :)
<libv> and tom, or at least one of his guys, is pretty readily providing binaries for distribution
<libv> why would he pick another name besides the already wellestablished cubie?
<Galland> afaik he even changed his cubie store's name to rock-store or something like that
<Galland> I read it a few days ago in a blogpost
<Galland> he hangs out here at times (hipboi), so you may be able to ask him directly :)
<Galland> there it is
<libv> interesting
soletti has joined #linux-rockchip
<ssvb> Galland: https://github.com/Galland/Linux3188/tree/master/drivers/video/rockchip/rga should be enough to get some basic information about RGA
<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> github.com/olegk0/xf86-video-fbdev
<Galland> though XV failed a bit (described in my blog: http://hwswbits.blogspot.com/2013/04/compiling-mali-hw-accelerated-driver.html )
<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
<Galland> by far the biggest source is:
<Galland> 48: 142211647 0 0 0 GIC dwc_otg, dwc_otg_hcd:usb1, dwc_otg_pcd
<ssvb> you can probably disable otg in the kernel for a cleaner experiment
<ssvb> you are using serial console on this device?
<Galland> nope, actually I'm on xfce with it right now chatting here :D
<ssvb> hmm :)
<Galland> yep :)
<Galland> that may explain some things
<Astralix> wow, havy development goin on here
<Astralix> so good evening (or whatever time it is at your site
<Galland> hi Astralix
<Astralix> Hi!
<ssvb> btw, who is the boss here? :) I mean the main kernel guy
<Astralix> gallad was most successfull last weeks
<Astralix> I had some family things to do
<hramrach> ohai
<Astralix> hi
<hramrach> ssvb: probably omegamoon
<Astralix> and I am trying to get my avatar name back
<Galland> me agrees with hramrach
<Galland> he is the one going after Mali on RK3188 right now
<ssvb> ok, good to know
<Astralix> I guess he is lying in the sun looking after girls
<Galland> on vacations, that is :D
<Astralix> ssvb, what is the question to the kernel guy?
<Galland> so currently (kernel Linux3188) we're getting some 8K interrupts per second from dwc usb
<Galland> same as Rasp.Pi guys were seeing before patching it
<Galland> I'll dive into this right now
<Astralix> That we should try to ping mmind00
<ssvb> Astralix: just wanted to say hello :)
<Astralix> he is porting 3xxx into mainline and there are several known issues
<Astralix> hi ssvb
<Astralix> are the 8k coming in even no device is connected?
<Galland> hmmm
<Galland> I'll check this with a timed-script since my keyboard is usb connected :D
<Astralix> cause 8k looks like a constant frame irq
<Galland> (no ssh for me :D)
<Astralix> no serial port?
mmind00 has joined #linux-rockchip
<Galland> pffff too lazy for that, just made the test
<Galland> no devices = no interrupts
<Galland> as expected
<Astralix> where di you buy the keyboard and are u sure that there is no keylogger installed?
<Galland> looool
<Astralix> but... if it is a normal HID device it is set up as USB 1.1 so it has 12MBit.
<Galland> I have several other devices connected
<Galland> however, the RPi guys reported the same 8K figure, so I guess it's not really related to the devices connected
<Astralix> ok, so you could try to find out which device is causing that traffic?
<Galland> I still have to find what the problem was for Rpi guys
<Galland> I mean, is 8000 events a second too much for a bus that is able of 480 Mbps and on a CPU with 4 cores at 1.6 GHz?
<Galland> that's one interrupt every 7 KBytes of data
<Galland> (if the bus is 100% used)
<Galland> however, I'll disconnect the USB Wifi, mouse and soundcard, leaving only the keyboard and check again irqs
<Galland> that will be USB 2.0 hub with just one USB 1.1 keyboard
<Galland> see you in a minute
<Astralix> wait
<Astralix> could you try to leave the soundcard out first?
<Galland> lol
<Galland> still 8K interrupts
<Astralix> I am scanning the rpi things but have mostly only reboot issues
<Astralix> and some rumors about soundcard issues
eebrah is now known as O_o
O_o is now known as O_o|eebrah
O_o|eebrah is now known as x_x|eebrah
<Galland> "the Synopsys driver relies on
<Galland> the start of frame interrupt for scheduling transfers if "descriptor DMA" is
<Galland> not implemented (which it isn't, on BCM2835). 8000 is one interrupt per
<Galland> microframe."
<Galland> anybody interested on the USB problems that RK shares with RPi, I've just blogged about my findings:
<Astralix> Did you try to implement some fix?
<Galland> not yet, but at the end of the post is the github repo commits for the fixes
<Galland> if anybody else is interested in testing
tonikasch has joined #linux-rockchip
mmind00 has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
<jpsminix> bye
jpsminix has quit [Quit: leaving]
* tonikasch ciao
tonikasch has quit [Quit: Bye!]
JochenKauz has joined #linux-rockchip
arokux2 has quit [Remote host closed the connection]
JochenKauz has quit [Quit: Leaving.]
Galland has quit [Quit: Saliendo]
tinti has quit [Read error: Connection reset by peer]
naobsd has quit [Quit: Page closed]
tonikasch has joined #linux-rockchip