Turl changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask and wait! - See http://linux-sunxi.org | https://github.com/linux-sunxi/ | Logs at http://irclog.whitequark.org/linux-sunxi
leviathanch has quit [Ping timeout: 245 seconds]
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Remote host closed the connection]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
aazzddgg has quit [Quit: Leaving]
ganbold has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
mrsalomao has joined #linux-sunxi
<mrsalomao> Hey guys. I was here friday, reporting that mouse movement was decreasing fps by about 50
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
<mrsalomao> in es2gears and other openglES applications.
<mrsalomao> I did the same test with the Cubiez image, and looks like moving the mouse around also heavily affects performance there too
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
k3rN has joined #linux-sunxi
<mrsalomao> Anyone who was able to reproduce and verify this? Video for reference: https://www.youtube.com/watch?v=n2-hC-vGD-w
k3rN has quit [Excess Flood]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
k3rN has joined #linux-sunxi
k3rN has quit [Excess Flood]
egbert has quit [Ping timeout: 276 seconds]
egbert has joined #linux-sunxi
<ssvb> mrsalomao: have you already tried to disable the ShadowFB option?
k3rN has joined #linux-sunxi
<ssvb> mrsalomao: ShadowFB inhibits some of the hardware acceleration features, having bad performance with it enabled is the expected outcome
pseudomind has joined #linux-sunxi
pseudomind has quit [Quit: pseudomind]
<mrsalomao> I'll try that and report, brb
seere has joined #linux-sunxi
lioka has quit [Ping timeout: 252 seconds]
seere_ has quit [Ping timeout: 264 seconds]
lioka has joined #linux-sunxi
pseudomind has joined #linux-sunxi
Alchemy has joined #linux-sunxi
Alchemy is now known as Guest49383
prism has joined #linux-sunxi
prism is now known as Guest43182
daemon has quit [Ping timeout: 264 seconds]
Guest49383 has quit [Ping timeout: 264 seconds]
Guest43182 is now known as daemon
FreezingCold has joined #linux-sunxi
nicksydney_ has joined #linux-sunxi
nicksydney has quit [Remote host closed the connection]
nicksydney_ has quit [Remote host closed the connection]
nicksydney has joined #linux-sunxi
lioka has quit [Ping timeout: 240 seconds]
TheSeven has quit [Ping timeout: 252 seconds]
TheSeven has joined #linux-sunxi
lioka has joined #linux-sunxi
slact has quit [Ping timeout: 240 seconds]
mrsalomao has quit [Ping timeout: 240 seconds]
bonbons has quit [Quit: Leaving]
JohnDoe_71Rus has joined #linux-sunxi
netchip|zZz has quit [Ping timeout: 252 seconds]
w00tc0d3 has joined #linux-sunxi
w00tc0d3 is now known as Guest97413
pseudomind has quit [Quit: pseudomind]
slact has joined #linux-sunxi
slact has quit [Ping timeout: 265 seconds]
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
shineworld has joined #linux-sunxi
leviathanch has joined #linux-sunxi
focus has joined #linux-sunxi
_massi_ has joined #linux-sunxi
maksimlin has quit [Quit: ChatZilla [Firefox 28.0/20140317233623]]
sehraf has joined #linux-sunxi
diego_r has joined #linux-sunxi
blsd has joined #linux-sunxi
FR^2 has joined #linux-sunxi
<ssvb> wens: does china-core offer any additional documentation about this MCTL (maybe in Chinese)? http://www.china-core.com/down/html/download/DDR2&DDR3_Data_Sheet%20v0.1.pdf
<wens> I don't see any on their website.
shineworld has quit [Quit: Sto andando via]
leviathanch has quit [Ping timeout: 240 seconds]
leviathanch has joined #linux-sunxi
blsd has left #linux-sunxi [#linux-sunxi]
Fusing3 has joined #linux-sunxi
jemk has joined #linux-sunxi
rm has quit [Quit: ZNC - http://znc.sourceforge.net]
<jemk> ssvb: have you tried turning off bank interleaving? if framebuffer and benchmark buffer are in different banks the overhead should vanish, therefor you'll lose seq. speed
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
rm has joined #linux-sunxi
rm has quit [Changing host]
rm has joined #linux-sunxi
<mnemoc> moin
<ssvb> jemk: yes, I tried to remove the DRAM_DCR_MODE_INTERLEAVE bit as part of the experiments, but the device does not boot after that
acr has joined #linux-sunxi
acr is now known as MrFoo
MrFoo is now known as MrBar
<ssvb> jemk: appears that the banks mapping configuration is more complicated than that
<ssvb> jemk: additionally, disabling banks interleave completely is a very bad idea
Fusing3 has quit [Ping timeout: 252 seconds]
<jemk> ssvb: yeah, sure, i only thought it could be a way to verify your theory
<jemk> ssvb: but it's strage that it doesn't even boot, i thought i had tried that
<ssvb> jemk: have you tried to reproduce the shaking screen problem yourself? even with a lower resolution monitor it is possible to downclock dram until i shows up
<MrBar> who write backlight driver for FB_SUNXI_LCD ?
<ssvb> jemk: also change "bus_width" from 32 to 16 and divide "size" by two if that's not enough
<jemk> ssvb: my a10 is doing real work, so i can't do experiments there at the moment
<ssvb> jemk: ok
<jemk> ssvb: but one idea, it could be important to have correct density and io-widtg for non-interleaving to work
<ssvb> jemk: the density and io width should be both correct
<ssvb> jemk: the real banks layout might be configurable via various bitfields from https://github.com/linux-sunxi/u-boot-sunxi/blob/06ad4bb62b69/include/synopsys/dwcddr21mctl.h#L66
<MrBar> why in disp_lcd.c realtime platform check performed?
<MrBar> why drivers code looks like writen by monkeys?
<oliv3r> MrBar: excellent questions, the pain of many of us
leviathanch has quit [Ping timeout: 255 seconds]
<MrBar> it not linux
<MrBar> it just android kernel
<MrBar> why it called linux?
<MrBar> it android quality code for low cost phones
<ssvb> MrBar: did you come here to cry on somebody's shoulder? ;)
<MrBar> :)
leviathanch has joined #linux-sunxi
<ssvb> the drivers are being fixed, cleaned up and mainlined, but this process is somewhat slow
<ssvb> jemk: the dram host ports configuration also has "0x240 APR arbiter period register" and "0x244 PLDTR priority level data threshold register"
<wens> oliv3r: hi there!
<ssvb> jemk: I tried to play with them a bit, but without much success
<ssvb> jemk: if the arbiter could be configured to make DEBE behave better, that could be also a potential solution
<ssvb> jemk: but I'm somewhat happy that at least DEFE seems to be problem-free now
cubear has joined #linux-sunxi
massifr has joined #linux-sunxi
<MrBar> great code from drivers: if (sunxi_is_sun4i()) msleep(20);
<MrBar> sun4i too fast
lioka has quit [Ping timeout: 252 seconds]
<massifr> cubear: thanks for your answer last friday; I had not marked my absence and I did not answer you; I apologize for that. Anyway, I've ordered the serial cable from olimex
<cubear> massifr: There is a UART0 port on your board, connect the serial cable to that (only connect GND, RX and TX, do not connect VCC), and see what debug info the board outputs
lioka has joined #linux-sunxi
<massifr> in a few days I'll have the cable; I've tried with an Olimexino-32U4 (@3.3V) acting as a sort of "serial port repeater", but that did not work; the board seems dead, but let's see what I can get from UART0 with the right cable
rz2k has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 272 seconds]
<MrBar> nice programing challenge – WEEK #51 from olimex
leviathanch has quit [Ping timeout: 240 seconds]
<torindel> MrBar: link or desc?
<specing> ... latest on Sunday April 27th
<specing> Why do I have a feeling they publish these challanges one week too late?
<MrBar> :)
<Wizzup> lol
lioka has quit [Ping timeout: 245 seconds]
<specing> No seriously. It has only happened to me once that I saw their challenge before it was due
<specing> and even then it was on a sunday ~3h from the deadline
wickwire has joined #linux-sunxi
<MrBar> someone know quality level of linux drivers code for i.MX based boards?
<Wizzup> It did seem like a nice challenge
antony11 has joined #linux-sunxi
lioka has joined #linux-sunxi
lioka has quit [Changing host]
lioka has joined #linux-sunxi
massifr has quit [Quit: Sto andando via]
MrBar has quit [Quit: Leaving]
orly_owl has quit [Ping timeout: 264 seconds]
atiti has quit [Ping timeout: 252 seconds]
deasy has joined #linux-sunxi
leviathanch has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
orly_owl has joined #linux-sunxi
mrsalomao635 has joined #linux-sunxi
<mrsalomao635> ssvb: I tried disabling the ShadowFB option in the xorg.conf file, but the problem persists. I've made a new video just to clarify what my problem is to others who might be willing to help: https://www.youtube.com/watch?v=Jo8qbR5xG50&feature=em-upload_owner
mrsalomao635 has quit [Client Quit]
lioka has quit [Ping timeout: 252 seconds]
leviathanch has quit [Ping timeout: 240 seconds]
bgal has joined #linux-sunxi
leviathanch has joined #linux-sunxi
lioka has joined #linux-sunxi
lioka has quit [Client Quit]
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Black_Horseman has joined #linux-sunxi
leviathanch has quit [Ping timeout: 264 seconds]
libcg has joined #linux-sunxi
leviathanch has joined #linux-sunxi
nove has joined #linux-sunxi
deffrag has joined #linux-sunxi
bgal has quit [Ping timeout: 252 seconds]
<nove> The correct message isn't been transmitted, and i don't know what wiki should have, other than more big red notices
<nove> is beyond comical
<Turl> specing: olimex published their challenges every friday, and they're due every sunday
Gerwin_J has joined #linux-sunxi
<Turl> publishes*
<rellla> nove: :)
<Turl> nove: let them be, they're talking about odroid :)
<rellla> nove: kind of a mixer in various forums, where sunxi/mali/cedarx is put together
shineworld has joined #linux-sunxi
<rellla> and nobody is asking or reading about the facts. just making a statement to have posted something. kind of frustrating...
<nove> did you also saw the linked mythtv thread
<rellla> vdpau seems to sit on blob drivers. yeah kind of, libmali if you want to :)
<rellla> don't waste your time, nove. it's more worthful!
leviathanch has quit [Ping timeout: 240 seconds]
<nove> well is the expected, when a gpu is required to display pixels in a screen => wayland
<libv> ...
<libv> nove: a gpu cares mostly about pushing pixels to some memory
<Turl> it's just that the people are stuck in the x86 paradigm
<Turl> where they buy "a GPU" that pushes the pixels, does the 3D and decodes their video
<libv> which is not true
<libv> it's just as modular on x86
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
<libv> but it does tend to fit on the same discrete graphics chip which is stuck on a separate graphics card
<libv> the blocks on that chip are segmented similarly as they are on an ARM SoC
<libv> the difference is that the same gpu, media, 2d and display engines tend to always occur as a set, and that the gpu does not tend to get paired with a completely different display engine
<libv> unless you of course consider ati radeon r500
<libv> where the display engine was completely written from scratch (and was a thing of beauty), whereas the gpu and 2d accel remained the same as from r300
<nove> libv: i know, was only criticizing wayland, that is creating a requirement of a need for a gpu to have a working desktop environment
<libv> nove: people have been trying to work to that requirement for a decade
<libv> nove: and there was a time when people didn't even want to care about the display/modesetting side of things
<Turl> "if it's there why not use it?"
<libv> Turl: i didn't make many friends with statements like that
<libv> another good one was "if it is separate in hardware, why can it not be separate in software?"
<Turl> libv: I've seen such statements many times on discussion about using gpu for compositing and drawing all the things
<libv> Turl: arguing for using only the gpu?
<libv> that's just laziness
<nove> but wayland is a nice plan, to force the blobs to follow FLOSS standards
<libv> just like the current intel graphics driver stack doesn't want to care about synchronization of the different engines, outside of the gpus command queue
<libv> nove: eh?
<libv> nove: what floss standards are that?
<nove> libv: i mean, to play well with kms, gallium and so
<libv> nove: so what about the rpi support?
leviathanch has joined #linux-sunxi
<nove> libv: yes that is different, but i think is not feature complete
<libv> so not much forcing there
<nove> libv: i am speaking of i don't know, so if wayland can be implement without a gpu great, but wasn't designed to fit the way modern gpu work
<libv> nove: i caused a minor stirr two years ago when i went to try to find out whether it worked on plain fb with software rendering
<libv> nove: seems no-one thought of implementing the absolute basic set of requirements, not even to be able to verify tests against
<libv> wayland is for intel, and from time to time, radeon and nouveau were also allowed to play, to the extent that they had to just implement what intel was doing
<libv> but this changed now that they have the rpi support
<libv> wayland is not a big political plan to get more open source support
<libv> wayland is an intel toy project
blsd has joined #linux-sunxi
<nove> libv: ok
<nove> libv: maybe sunxi support?
<nove> libv: ah mistake, sunxi is not worth enough the trouble, because of the other gpu
<ssvb> Turl: that's nice, though A10 and A20 can run dram at 552MHz too with a bit of dcdc3 voltage increase and proper calibration
<libv> nove: sunxi will take part of the intel route
<nove> using the gpu, right
<ssvb> Turl: maybe they just have fixed some blatant dram initialization bugs in the A23 bootloader? :)
<Turl> ssvb: who knows :)
<ssvb> do we have the sources of the A23 bootloader?
<Turl> ssvb: I believe we have boot0
<Turl> they killed boot1 with fire it seems
<Turl> they just chainload uboot now
<Turl> ssvb: ask oliv3r
<Turl> or wens
focus has quit [Remote host closed the connection]
leviathanch has quit [Ping timeout: 240 seconds]
<nove> juanfont: i have to ask, do you got any further with the sunxi allocator?
leviathanch has joined #linux-sunxi
<nove> is simples to wrap the allocator in the blobs, so i go this way
<nove> to do this allocator in the kernel is too trouble, only to make blobs happy
popolon has joined #linux-sunxi
popolon has joined #linux-sunxi
kuldeepdhaka has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
focus has joined #linux-sunxi
pseudomind has joined #linux-sunxi
pseudomind has quit [Client Quit]
nicksydney has quit [Ping timeout: 264 seconds]
byECHO has joined #linux-sunxi
atiti has joined #linux-sunxi
<byECHO> libv are you there?
leviathanch has quit [Ping timeout: 255 seconds]
deasy has quit [Ping timeout: 240 seconds]
FDCX has quit [Remote host closed the connection]
xinj has joined #linux-sunxi
FDCX has joined #linux-sunxi
xinj has quit [Remote host closed the connection]
xinj has joined #linux-sunxi
deasy has joined #linux-sunxi
<nove> ^ suspicious
xinj has quit [Ping timeout: 264 seconds]
dlan^ has joined #linux-sunxi
dlan^ has joined #linux-sunxi
byECHO has quit [Quit: Page closed]
xinj has joined #linux-sunxi
shineworld has joined #linux-sunxi
<juanfont> nove, not yet. I've been pretty busy :(
<nove> juanfont: ok, it up to you if you do it
<nove> juanfont: i will go with a wrapper, as you see above, this blobs have artificial software limits in it
<juanfont> I know. But I'm not very sure if it would be very interesting. I mean... the encoder expects a very particular format (probably from a camera). Having something like this http://www.raspberrypi.org/forums/viewtopic.php?f=70&t=25022 could be really difficult
<nove> juanfont: hardware decoder => hardware encoder, is possible without conversion
<juanfont> is the hardware capable of handling that?
<nove> juanfont: but software decode => hardware encoder, in this case conversion is need
bbrezillon has joined #linux-sunxi
<nove> the hardware encoder use a subengine isp but even doesn't accept normal rgb as input
<nove> juanfont: if what you want to transcode can be decoded by hardware, yes
<nove> juanfont: new versions of cedar hardware, can even do tasks of decode/encode simultaneous (must be verified)
xinj has quit [Read error: Connection reset by peer]
rz2k has quit []
<juanfont> where did you get that info? Are we sure old hardware is not capable of doing that?
<nove> juanfont: old version can be done, by interleaving decode1 => encode1 => decode2 => encode2
<nove> juanfont: new can decode1 => decode2/encode1 => decode3/encode2
<juanfont> that shouldn't be imposible to implement :)
<juanfont> ^(2nd paragraph)
<ssvb> juanfont: ask jemk
<jemk> juanfont: i'm trying to write a v4l codec driver, but i'm not sure wether that will work
<juanfont> i didn't even know that existed
HeHoPMaJIeH has quit [Remote host closed the connection]
<nove> jemk: lets do how wingrime said, before writing source code, lets go step by step check each v4l controls and what hardware must do
<jemk> i'm not worried about that, it fits pretty good. but normally firmware handles all the hard stuff (header decoding, reference picture handling...), we would have to do that in kernel space and i don't know if that is acceptable
<nove> few days back, i asked why in gallium, the response was that, the problem of bitstream parsering in the kernel
<wens> ssvb: we have the binary for a23 boot0
<jemk> nove: yep, but if we can't do it in kernel we can't use the (existing) v4l codec api
<nove> jemk: also freedreno has the advantage of the gpu is capable of handle the tile format of the vpu
dlan^ has quit [Quit: Lost terminal]
<nove> jemk: i have v4l bias, so only checking the possibilities
<ssvb> wens: but a23 is using the same dram controller as a31, which is different from a10/a13/a20? right?
hansg has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<wens> correct
<wens> and we have 2 versions of dram init code from Allwinner's A31 u-boot and A23 kernel
<wens> but they are somewhat different, and I haven't been able to make sense of it
<ssvb> jemk: about the a10/a13/a20 dram timings, I'm a bit worried about the "reserved" bit field in dram_tpr1, bits [15:12]
xavia has joined #linux-sunxi
<ssvb> jemk: the RK30XX manual says that they are reserved and RO, but the cas6 set for sunxi devices has it as 1 and the cas9 set has it as 10
bbrezillon has quit [Quit: WeeChat 0.4.1]
<ssvb> jemk: other than this, I think the dram timings calculator should be already more or less complete
<ssvb> jemk: I'm also applying the extra RK30xx timing rules - https://github.com/ssvb/a10-meminfo/blob/feb1131258d80e30/a10-dram-timings-calculator.rb#L134
cosm has quit [Read error: Connection reset by peer]
<ssvb> jemk: it would be also a good idea to use dram chip specific tRFC instead of the default failsafe JEDEC values
mrsalomao has joined #linux-sunxi
<mrsalomao> ssvb: I tried disabling the ShadowFB option in the xorg.conf file, but the problem persists. I've made a new video just to clarify what my problem is to others who might be willing to help: https://www.youtube.com/watch?v=Jo8qbR5xG50&feature=em-upload_owner
<mrsalomao> ssvb: sorry for double posting this, just want to make sure my message doesn't get buried :P
<Wizzup> I have small Q about fex; I have enabled uart0 and uart2 (port 0 and 2 respectively, set with uart_port)
<ssvb> mrsalomao: can you check the cpu usage when running es2gears? is it 100% or less than that?
<Wizzup> when booted (after generating script.bin), it seems that /dev/ttyS{0,1} are both "working"
<Wizzup> where working really means, cat doesn't give an error
<Wizzup> I'd expect ttyS{0,2} to be the working ones
<Wizzup> (there are not others enabled, except for the uart_port=0 and uart_port=2
<Wizzup> no others*
<mrsalomao> ssvb: gonna check, brb
<Wizzup> nevermind: [ 1.144590] sunxi-uart.2: ttyS1 at MMIO 0x1c28800 (irq = 3) is a U6_16550A
hansg has quit [Quit: Leaving]
<blsd> hey guys did anyone try weston on cubietruck?
discopig has quit [Ping timeout: 245 seconds]
<jemk> ssvb: it looks like bwdsp100 has a very similar memory controller, they have [13:12] trnkrtr and [15:14] trnkwtw
<jemk> ssvb: and i don't have any problem with setting ram to sequential (on a20), it boots and tinymembench reports lower bandwidth
<ssvb> jemk: hmm, maybe I need to try it again with sequential, on both a20 and a10
shineworld has left #linux-sunxi [#linux-sunxi]
discopig has joined #linux-sunxi
<ssvb> jemk: do you have a link to this bwdsp100 memory controller information?
<mrsalomao> ssvb: Indeed, CPU usage is very high, at 100%
<mrsalomao> ssvb: What do you think could be causing this? I did the same benchmarking with a QT4 application I developed myself and the same happened. Notice I didn't even implement mouse handling callbacks, so it must be something prior the the application layer, I think.
<ssvb> jemk: google does not return anything usable for me when asked "bwdsp100 trnkrtr"
<ssvb> mrsalomao: apparently you don't have "fb0_framebuffer_num = 3" in your fex file
<ssvb> mrsalomao: but in any case, it is partially a cubiuntu configuration issue
<mrsalomao> Hmm, I remember that value was '4' by default in cubiuntu
<ssvb> mrsalomao: is it still set to 4? anything biggger than 2 should be fine
<mrsalomao> ssvb: Hmmm
<mrsalomao> ssvb: yes. :/
<ssvb> mrsalomao: can you pastebin your /var/log/Xorg.0.log somewhere?
<mrsalomao> ok
<jemk> ssvb: does google really produce different results for me? the first and only result is exactly what i have used (yes, its chinese)
mrsalomao2 has joined #linux-sunxi
<ssvb> jemk: should I load this flash crap from this link?
bgal has joined #linux-sunxi
<jemk> ssvb: i guess so, i think to download it one has to pay
<ssvb> jemk: heh, I have flash blocked in my browser
<mrsalomao2> ssvb: ok, here you go. http://pastebin.com/aKF1vmAN
<jemk> i didn't find anything else, but the information is pretty valuable once you figure out what it means
<ssvb> jemk: did you pay them yourself or something?
<jemk> ssvb: i used the flash thing
<mrsalomao2> ssvb: that was my Xorg.0.log. This is is my .fex, in case you are interested too: http://pastebin.com/LKM1Czzg
<mrsalomao2> ssvb: In case there's anything else you need, just tell me, I'm sending this from my cb2, now
Gerwin_J has quit [Quit: Gerwin_J]
FR^2 has quit [Quit: Connection reset by peer]
<ssvb> jemk: sorry if I'm bothering you with this trivia stuff, but could you please google translate what they say about [13:12] trnkrtr and [15:14] trnkwtw there?
<jemk> ssvb: that's the problem, you can't copy paste it...
<ssvb> jemk: heh, maybe wens can help?
<ssvb> jemk: based just on the name, sounds like something read-to-read and write-to-write truncate?
<mrsalomao2> ssvb: Here's a printscreen showing CPU usage as well: http://www.zimagez.com/zimage/screenshot-042814-181823.php
<ssvb> mrsalomao: does it look more like 70-80% and not 100%?
<ssvb> mrsalomao: also you have two cores, so I'm not sure how to interpret this indicator
<jemk> ssvb: the first two characters mean different and then there is rank in latin characters, so i guess its some timing when switching ranks (which we don't use on any board i know of)
<ssvb> mrsalomao: can you run 'htop' in a separate terminal and check what it says?
<jemk> ssvb: but more i don't understand
<ssvb> jemk: ok, thanks :) I guess we can safely ignore these bit fields, and maybe just run some tests with setting them to all 0 and all 1
<ssvb> jemk: about the other bit fields, are they in the same place with the same names in bwdsp100?
<jemk> ssvb: yes, i think all i checked till now are exactly the same, but the controller is for ddr1/ddr2, so there is some difference
<jemk> ssvb: and for refresh timing there is this magic subtract 200 I removed in our u-boot because i thought its some allwinner added stuff
<jemk> ssvb: maybe i shouldn't have removed it :(
<jemk> ssvb: rRFPRD[23:8] = (tREFI/tclock)*(RFBURST+1)-200
<ssvb> jemk: I guess either way is fine, that's the interval between refreshes, it is temperature dependent and probably still has a lot of safety margin
<jemk> ssvb: yeah, for normal temperatures it should be no problem, lets hope nobody wants to run it at 80C
<jemk> ;)
blsd has left #linux-sunxi [#linux-sunxi]
<mrsalomao2> ssvb: this is while I was moving the mouse around: http://www.zimagez.com/zimage/screenshot-042814-183203.php
<ssvb> jemk: but tRFC (the duration of the refresh itself) is 260ns for the MEMPHIS dram chips in A10-Lime, while JEDEC suggests to have it as 300ns for density 4096
<ssvb> jemk: we can shave off the whole 40ns :)
<ssvb> mrsalomao2: and what happens if you don't move the mouse around?
<mrsalomao2> ssvb: Now, after some time not moving the mouse: http://www.zimagez.com/zimage/screenshot-042814-183203.php
<mrsalomao2> ^
<Turl> mrsalomao2: it would be interesting to see the process names
<mrsalomao2> Turl: how can I do that? Sorry for my newbyness :P
<Turl> mrsalomao2: make the htop terminal bigger or move the columns (right arrow key)
<jemk> ssvb: then we have to introduce more dram.tpr* and add refresh timing there too
<Turl> so that at least cpu% and command are visible
<ssvb> jemk: tRFC is one of the bit fields in tpr1
<jemk> ssvb: really?
<jemk> that would be new to me
<ssvb> jemk: yes [23:16], and it is set to 0 for most boards
bgal has quit [Ping timeout: 252 seconds]
<jemk> nonono, thats only true on rk30xx... tpr1 is different on our controller
<ssvb> jemk: maybe allwinner or the dram controller vendor have moved it around, but we still have place for it reserved there
<ssvb> jemk: what is it on our controller?
<ssvb> jemk: does bwdsp100 provide some hints about it?
bertrik has joined #linux-sunxi
bertrik has quit [Changing host]
bertrik has joined #linux-sunxi
<jemk> ssvb: uh, i really didn't mention that. [22]:16] reserved, [26:23] XCL, [30:27] XWR, [31] TP, the reserved matches exactly to what happens when writing ~1 to tpr1
<mrsalomao2> Thats without moving the mouse
<jemk> s/~1/-1/
<jemk> ssvb: but don't ask me what those mean again ;)
<Turl> mrsalomao2: old link? I see the same
<mrsalomao2> SORRY LOL
<jemk> ssvb: but it looks like TP enables XCL and XWR somehow
bonbons has joined #linux-sunxi
<mrsalomao2> Sorry, this is the one where I dont move my mouse: http://www.zimagez.com/zimage/screenshot-042814-184050.php
<mrsalomao2> (last 2 were repeated)
tomboy65 has joined #linux-sunxi
<ssvb> mrsalomao2: based on the screenshots, everything looks normal, there is nothing to fix
<ssvb> mrsalomao2: in the graphics drivers setup at least
<mrsalomao2> ssvb: so what could explain a 50fps drop for moving the mouse around?
<ssvb> mrsalomao2: well, maybe because you are moving the mouse around and disturbing it by doing this?
<mrsalomao2> ssvb: yea, I expected this to cause a performance hit. But not such a big one
<mrsalomao2> ssvb: but maybe thats the price we pay for having HWCursor (?)
<ssvb> mrsalomao2: what is your cpufreq governor?
<ssvb> mrsalomao2: does it work better with the software cursor?
<mrsalomao2> ssvb: idk, how can I see that?
<ssvb> mrsalomao: run 'cpufreq-info' in the terminal
<mrsalomao2> ssvb: nope, HWCursor is way better, overall
<mrsalomao2> cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: sunxi CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 2.00 ms. hardware limits: 60.0 MHz - 1.01 GHz available cpufreq governors: userspace, interactive, performance current policy: freq
<ssvb> what does it say about the current governor? and please use pastebin for large logs
<mrsalomao2> ssvb: sorry about that, there it is
<ssvb> looks like the "performance" governor
<ssvb> so the cpu must be running at full speed and the high cpu usage is indeed a bit strange
<mrsalomao2> ssvb: hmm
<mrsalomao2> ssvb: for a program like "es2gears" it is
<ssvb> because 70% out of 60MHz is a bit different from 70% out of 1GHz :)
<Turl> are you sure it's using the mali libs?
<ssvb> Turl: that's a good question :)
<Turl> run es2info or something like that to check the vendor strings
<mrsalomao2> Turl: In the Xorg.0.log file I posted here, it said something about failing to load LIMA drivers
<Turl> mrsalomao2: yes, that's kinda expected
<ssvb> mrsalomao2: the blob is loaded on the client side in es2gears, the X server is only presenting the ready made frames on screen
<Turl> looks correct
<Turl> mrsalomao2: maybe you can try the newer one that uses the 2 mali thingies
<Turl> ssvb?
<mrsalomao2> Turl: the new mali blobs?
<Turl> there's a newer set of blobs to use the two PPs I think (or what are they called?)
<Turl> but you need to upgrade the kernel driver as well
<Turl> ssvb should be able to explain :)
<mrsalomao2> Turl: I'm not quite sure if I'd be able to accomplish that ahahhaha. I'm a poor Ubuntu user mortal
<ssvb> jemk: tried DRAM_DCR_MODE_SEQ on the cubieboard2 and the cubieboard1, the former boots and the latter does not
<ssvb> jemk: sigh, and we really want to test this specifically on Allwinner A10 (cubieboard1)
smotocel69 has quit [Remote host closed the connection]
_massi_ has quit [Remote host closed the connection]
<ssvb> mrsalomao2: well, it looks like es2gears just sucks and uses too much cpu for whatever reason
<ssvb> mrsalomao2: try some other gles app :)
<mrsalomao2> ssvb: I tested it with a simple opengles application I did too, using QT
notmart has quit [Quit: notmart terminated!]
<mrsalomao2> ssvb: all it did was display a rotating cube. Nothing else. Didn't even receive mouse events.
<ssvb> mrsalomao2: there is always a rotating horse, aka glmark2-es2
<jemk> ssvb: ok, then a10 is really different
<jemk> ssvb: i've updated tpr registers in wiki
<jemk> ssvb: i'm pretty sure this is correct, all sources i found till now and compared to writeable bits
<mrsalomao2> Ok, just tested it. First 2 sub-benchmarks in glmark-es2 (NOT MOVING THE MOUSE) -> [build] use-vbo=false: FPS: 243 FrameTime: 4.115 ms [build] use-vbo=true: FPS: 330 FrameTime: 3.030 ms
<ssvb> jemk: thanks!
<mrsalomao2> Now moving the mouse -> [build] use-vbo=false: FPS: 88 FrameTime: 11.364 ms [build] use-vbo=true: FPS: 54 FrameTime: 18.519 ms
<mrsalomao2> From 243 FPS to 88 FPS
<mrsalomao2> From 330 FPS to 54 FPS
<mrsalomao2> Btw, I noticed that if I use a Wacom tablet I have laying around here, the performance impact is much smaller
diego_r has quit [Ping timeout: 252 seconds]
<mrsalomao2> glmark-es2, moving the mouse around with a Wacom tablet:
<mrsalomao2> [build] use-vbo=false: FPS: 215 FrameTime: 4.651 ms [build] use-vbo=true: FPS: 267 FrameTime: 3.745 ms
<ssvb> jemk: actually the cb1 is not completely dead, I get a nicely colored garbage on the monitor before it dies, so it at least tries to initialize disp
pseudomind has joined #linux-sunxi
<ssvb> jemk: but it's in a nice plastic box and I'm reluctant to unscrew it to connect the serial console :)
<mrsalomao2> Sorry, ignore the last mouse moving benchmark, it was that bad because there was another console window on top of it. Here's an unbiased one:
<mrsalomao2> [build] use-vbo=false: FPS: 210 FrameTime: 4.762 ms [build] use-vbo=true: FPS: 248 FrameTime: 4.032 ms
smotocel69 has joined #linux-sunxi
<mrsalomao2> Interesting fact: moving the mouse inside the opengl window causes a noticeable smaller framerate impact
<mrsalomao2> instead of falling from 350 fps to 260, it falls to about 300
bonbons has quit [Quit: Leaving]
bonbons has joined #linux-sunxi
mrsalomao2 has quit [Quit: Page closed]
bonbons has quit [Client Quit]
libcg has quit [Ping timeout: 252 seconds]
mrsalomao has quit [Quit: irc2go]
bonbons has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
smotocel69 has quit [Quit: Leaving]
mdp has quit [Excess Flood]
mdp has joined #linux-sunxi
mripard has quit [Remote host closed the connection]
<ssvb> jemk: the last update for the tpr3 scanner looks something like this - http://people.freedesktop.org/~siamashka/files/20140428-sunxi/sunxi-dram-tpr3-tests.html
<ssvb> jemk: trying to compare "dram_zq = 0x7f" + "dram_emr1 = 0x4" with "dram_zq = 0x7b" + "dram_emr1 = 0x0" there
wickwire has quit [Remote host closed the connection]
Skaag has quit [Ping timeout: 252 seconds]
ecelis has quit [Ping timeout: 252 seconds]
deasy has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
tomob has joined #linux-sunxi
bonbons has joined #linux-sunxi
pseudomind has quit [Quit: pseudomind]
Skaag has joined #linux-sunxi
<oliv3r> hey hey hey all
ecelis has joined #linux-sunxi
<oliv3r> just dropping by to let ya'll know I miss you all; I haven't forgotten about sunxi and have some time again hopefully very soon
<oliv3r> but new $job is amazing :)
<jemk> ssvb: hm, maybe we should start by verifying correctness of u-boot: http://sprunge.us/QCOP
<jemk> ssvb: and thats only the zq related part
<ssvb> jemk: yes, zq handling is pretty much messed up, that's why I'm trying to get the 'experimental' data just to see if it has any impact at all
<jemk> ssvb: if we assume that bit31 and the while is the zq calibration, then it won't have much effect
<ssvb> jemk: the RK30XX manual does not seem to be helping much, as the registers seem to be rather different
<WarheadsSE> oliv3r: good to hear
<ssvb> jemk: there is just DDR_PHYCTL_ZQ0CR1 register, which has the familiar default value 0x0000007b in the RK30XX manual
<ssvb> jemk: maybe some older allwinner hardware used the 'zq' parameter as-is, but now the lower byte gets shifted by 20 bits
<ssvb> jemk: does bwdsp100 have a magic answer for this? :)
<jemk> ssvb: i'm searching
tomob has left #linux-sunxi [#linux-sunxi]
<Turl> oliv3r: hey hey :)
<Turl> oliv3r: what are you working on?
<oliv3r> ssvb: timings calculator? i have missed out!
<ssvb> oliv3r: yes, though it is wrong, because it tried to follow the rk30xx manual precisely
<ssvb> oliv3r: and we have a slightly different revision of the dram controller as pointed by jemk
<jemk> ssvb: thats from bwdsp, zqcr0 looks good, but zqcr1 the shifts dont really fit: http://sprunge.us/djIh
massifr has joined #linux-sunxi
<ssvb> jemk: the worst thing is that we don't know if the code from boot0 is even making any sense at all, and the accurate documentation is missing
bgal has joined #linux-sunxi
<jemk> ssvb: thats another rockchip controller, not the one described in rk30xx manual, but its also not the same as ours
cubear has quit [Quit: Leaving]
nove has quit [Quit: nove]
Black_Horseman has joined #linux-sunxi
popolon has quit [Quit: Quitte]
Skaag has quit [Ping timeout: 252 seconds]
<oliv3r> Turl: for $job?
<oliv3r> ssvb: so we atleast know that ours is somewhat similar
<oliv3r> ssvb: still, progress is progress and you two made me very happy :)
<oliv3r> ssvb: i would not be supprised if our u-boot/boot0 code is a copy paste hack job; that just happens to work by sheer luck
Skaag has joined #linux-sunxi
tomboy65 has quit [Write error: Connection reset by peer]
tomob1 has joined #linux-sunxi
tomboy65 has joined #linux-sunxi
<Turl> oliv3r: yep
<oliv3r> wens: i wrote a u-boot prcm driver that was untested a while ago (re: http://linux-sunxi.org/PRCM)
jemk has quit [Quit: leaving]
Skaag has quit [Ping timeout: 265 seconds]
<oliv3r> Turl: ultimaker.com :)
bonbons has quit [Quit: Leaving]
<Turl> oliv3r: :)
<Turl> I didn't know software freedom conservancy existed
massifr has quit [Quit: Sto andando via]
notmart has quit [Quit: notmart terminated!]
<oliv3r> and i just realized, i think i was last working on some u-boot stuff for ijc and i may have completly forgotten!
<oliv3r> ijc: sorry :(
deffrag has quit [Ping timeout: 240 seconds]
bgal has quit [Ping timeout: 255 seconds]
nicksydney has joined #linux-sunxi
<hno> The boot0 code do not look like a copy-paste mashup from some other. Looks very much like a hardware rtl engineer writing a driver.
<hno> ssvb & jemk (re dram code)
bbrezillon has joined #linux-sunxi
tomob1 has left #linux-sunxi [#linux-sunxi]
nicksydney_ has joined #linux-sunxi
nicksydney has quit [Ping timeout: 264 seconds]
sehraf has quit [Quit: www.miranda-fusion.de ... be part of it...]
<torindel> btw do we have orginal boot0/boot1/boot2 sources?
Skaag has joined #linux-sunxi
<Turl> boot2? o.O
deffrag has joined #linux-sunxi
<Turl> torindel: for some SoCs I believe we have boot0/1 code
maksimlin has joined #linux-sunxi
<torindel> Turl: boot.axf (not boot2 ;])
<torindel> Turl: any links for that?
<Turl> oliv3r ^^^
gzamboni has quit [Ping timeout: 246 seconds]
_whitelogger has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
cajg has quit [Ping timeout: 252 seconds]
xavia has left #linux-sunxi ["PART #interlock :PART #arduino :PART #wnydev :PART #buffalolab :PART #docker :PART #symfony :PART #virtuvia :PONG :verne.freenode.net"]
cajg has joined #linux-sunxi