<rellla>
wingrime1: i saw you figured out some deint registers...
<wingrime1>
Rela i have much info
<vector80>
Hi everyone, I have a question... But it is about android, I am sorry to ask in here... In linux-sunxi, after I boot, I see that I can modify CpuFreq settings for both two core for A20
<vector80>
But in android kernel, after I boot, I only can see CPU0, I can't see CPU1
<hipboi>
cpu1 is killed :)
<wingrime1>
Rella: looks like we have alpha blend unit in main register set
<vector80>
And in android, there is fantasys for governor, is that one can be used to setup cpufreq for CPU1 in android ?
<libv>
mediatek thinks "everyday genius" is a good marketing strategy?
<libv>
it reeks of chinese misinterpretation of english
<ZetaNeta>
i got a mediatek, and i dont care about "everyday genius". I care about normal linux drivers
<libv>
well, mediatek seems big on linaro
<libv>
yet what do we get for that in return?
<libv>
also, did we ever get that a23 u-boot code out of allwinner?
<libv>
or has their linaro move made them feel all warm and good about themselves, so that they now feel they do enough of this open source malarky that they no longer need to bother with anything else
<libv>
(like i predicted)
Skaag has quit [Ping timeout: 276 seconds]
nicksydney has joined #linux-sunxi
Skaag has joined #linux-sunxi
<wens>
libv: oliv3r (gone?) said he's waiting for his tablet to arrive and then fire back an email
Skaag_ has joined #linux-sunxi
Skaag has quit [Ping timeout: 252 seconds]
<libv>
wens: he's been waiting for at least a month now :)
<wens>
that's true :(
FR^2 has joined #linux-sunxi
<wens>
mediatek drivers... might have to wait a bit, I heard they had a whole bunch of developers poached by Chinese design firms (and Samsung)
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
<wingrime1>
rella: take a look at cedar regs again
<rellla>
wingrime1: see it ;)
<wingrime1>
I barely sure that is alpha blender
<wingrime1>
But command queue....
Xaros has joined #linux-sunxi
Black_Horseman has quit [Ping timeout: 240 seconds]
rz2k has joined #linux-sunxi
joedj has quit [Ping timeout: 240 seconds]
<wens>
allwinner's website now has complete features for A80
<Turl>
wens: they also have publicly available pdf briefs
joedj has joined #linux-sunxi
* Xaros
is away: Min enoxleite to nekro8afti... krataei ftyari!!!
<wens>
how come the brief lists "low power LTE connectivity"
<Turl>
wens: HSIC
<wens>
isn't HSIC for USB?
<Turl>
wens: it's "low power usb"
<Turl>
wens: because it doesn't have transceivers, it's chip to chip on a max length of 10cm
<wingrime1>
I hope get samples
<wens>
meaning you connect an HSIC LTE chip? isn't that misleading?
<Turl>
wens: misleading how? :p
<wens>
I thought they built in an LTE modem
<Turl>
AW doesn't develop radios, so no :p
<wens>
libv: oh, we have A23 u-boot from the SDK, just no boot0 source code :(
geecko has joined #linux-sunxi
dude_it has quit [Quit: Sto andando via]
Skaag_ has quit [Ping timeout: 240 seconds]
Skaag has joined #linux-sunxi
lioka_ is now known as lioka
lioka has quit [Changing host]
lioka has joined #linux-sunxi
diego_r has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has quit [Changing host]
HeHoPMaJIeH has joined #linux-sunxi
nabblet has quit [Ping timeout: 276 seconds]
nabblet has joined #linux-sunxi
deasy has joined #linux-sunxi
<rellla>
wingrime1: those argb and maf registers belong to encoder?
<libv>
Turl, mnemoc: the exynos guy are having horrible spammers
<libv>
guys even
<libv>
on their wiki
<wingrime1>
Not realy, maf used for interlance video filter
<libv>
how is this being handled on our wiki?
<rellla>
wingrime1: but there is interfaced handling in display engine frontend, too. must deinterlacing be done two times? *confused*
<wingrime1>
Maf are using many frames for filter
<wingrime1>
Disp cant do much with single video frame
<Turl>
that should stop User:* spam; if someone wants to edit their user page, they need to ask you and you need to add them to the people group via the wiki admin
<Turl>
Wizzup: once you're ready to open the flood gates, you may want to set up an ifttt trigger with the recentchanges feed so you can crack down on spam instantly if it appears again :)
ganbold_ has joined #linux-sunxi
wingrime1 has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
<Wizzup>
ack
<vector80>
Hi all, I have a problem with my android kernel as follows: http://sprunge.us/jbLZ
<vector80>
Does anybody have an idea ?
wingrime1 has joined #linux-sunxi
wingrime has quit [Ping timeout: 265 seconds]
Philippe_Fouquet has joined #linux-sunxi
wingrime1 has quit [Read error: Connection reset by peer]
<Turl>
vector80: I think the cpus share the clock, so it doesn't make much sense to have 2 of them
wingrime has joined #linux-sunxi
jemk has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
wingrime1 has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
wingrime1 has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
wingrime1 has joined #linux-sunxi
wingrime has quit [Ping timeout: 250 seconds]
wingrime has joined #linux-sunxi
wingrime1 has quit [Ping timeout: 240 seconds]
wingrime1 has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
wingrime1 has quit [Client Quit]
wingrime has joined #linux-sunxi
Xaros has quit [Quit: Zwi se logou mou!!!]
FunkyPenguin has quit [Ping timeout: 252 seconds]
FunkyPenguin has joined #linux-sunxi
wingrime1 has joined #linux-sunxi
wingrime2 has joined #linux-sunxi
wingrime1 has quit [Read error: Connection reset by peer]
wingrime has quit [Read error: Connection reset by peer]
wingrime2 has quit [Client Quit]
diego_r has quit [Read error: No route to host]
wingrime has joined #linux-sunxi
diego_r has joined #linux-sunxi
diego_r has quit [Client Quit]
wingrime1 has joined #linux-sunxi
wingrime1 has quit [Read error: Connection reset by peer]
wingrime1 has joined #linux-sunxi
wingrime has quit [Ping timeout: 252 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<vector80>
Turl: Thank you very much, but I am currently checking with many other devices.
<vector80>
I am comparing with Samsung Galaxt Note 2, Note3, Amlogic...
<vector80>
All these have CPU cores mostly online allways
<vector80>
And also sunxi kernel, CPU1 is allways online also
<maz_>
ijc: where are your latest u-boot patches?
<vector80>
What is the difference between sunxi kernel and aw kernel for cpufreq ?
<Turl>
different governor
<Turl>
switch to ondemand or interactive
<vector80>
I switched to PERFORMANCE
<vector80>
but CPU1 is still not online
<vector80>
it is mostly offline, it gets online when it is really processing a lot
<vector80>
but that causes system laggy sometimes
<vector80>
until CPU1 gets wake up,
<vector80>
some time is lost
<vector80>
but sunxi kernel is much better
<vector80>
CPU1 is almost allways online
Net147 has quit [Quit: HydraIRC -> http://www.hydrairc.com <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :)]
<hipboi>
vector80, yeah
<hipboi>
vector80, that's the problem
<ijc>
maz_: git://gitorious.org/ijc/u-boot.git has branches with a -vN suffix, so the latest is there. I can pull out my laptop and be more specific if you need me to be ;-)
<ijc>
I think I'm up to v2, which was a while back, but i'm just about done with all the cleanups needed for v3. I don't think any of the differences will matter for your PSCI stuff though
<maz_>
ijc: thanks. I'll have a look at putting it all together again. need to bring a CT at work so I can get the job done without being moaned at at home... ;-)
<ijc>
My wife has evening classes, whichis how I manage ;-)
<maz_>
ijc: I'm making some progress. Dynamic memory allocation in SPL, and MMC converted to the new scheme. Still getting a timeout, but better than nothing. I'll push my patches out, feel free to grab them or not.
<ijc>
Not sure what state my current v3 branch is in or I'd throw it your way. Might have a chance to finish it off over the break.
<ijc>
if I do get a chance I'll look at your stuff too
<jemk>
ssvb: any news from the dram side? I added a second run on cubietruck with 600mhz, only two cells are green then.
Philippe_Fouquet has quit [Ping timeout: 240 seconds]
<ssvb>
jemk: yes, I'm sitting on a pile of more advanced scripts and need to clean them up to remove debugging hacks
<ssvb>
jemk: I have also updated lima-memtester to add support for MEMTESTER_EARLY_EXIT environment variable to speed up the testing process
kivutar has quit [Quit: Ex-Chat]
<jemk>
ssvb: and i thought about a possible problem with the way the scripts work, because normally data training has to be done after setting up the dlls, but only u-boot does that
<jemk>
ssvb: that could reduce the accuracy of the results
<ssvb>
jemk: well, the RK30XX manual says that the DLLs can be configured at runtime (maybe with a momentary glitch which might kill the system if we are very unlucky)
<jemk>
ssvb: more speed is good, maybe I can test cb1 somehow, but it does real work at the moment, no way to reboot all the time
<ssvb>
jemk: it says "As part of the optimization of this PHY, the DDR3 write leveling feature is not supported." and at the same time "Real time DQS drift detection and compensation"
megal0maniac_afk is now known as megal0maniac
<jemk>
ssvb: after scan_read_pipe the rslr and rdqsgr regs contain new values, so it really does dqs gate training
<ssvb>
jemk: yes, the DQS gate training is mentioned in the RK30XX manual
<jemk>
ssvb: i think they only mean they don't support the special mode to do the write leveling where the ddr chip forwards clk(or dqs?) to dq
<jemk>
ssvb: to really detect the correct shift, not to guess it based on errors
<libv>
wens: ?
<libv>
the ram and nand chips aren;t important, and do not help with identification
<libv>
plus, this is not information that android will give to you
<libv>
ah, i should clarify that in those two sections.
<ssvb>
jemk: I just wonder what kind of training we are actually doing here, and whether the DQS gate training really has some influence on it
geecko has quit [Ping timeout: 276 seconds]
<ssvb>
jemk: maybe we can try to boot the system with different initial tpr3 and see if this affects the results
<jemk>
ssvb: thats a good question, I neither really know what we are doing
<ssvb>
jemk: it seems to be reassuring in the sense that the static hardcoded shifts/delays configuration is also used by the others
<ssvb>
jemk: and this configuration seems to be indeed mostly board/device specific
<ssvb>
jemk: btw, the memtester log can be indeed used to correctly identify which byte lane is failing, this works :)
<jemk>
ssvb: the freescale manuals are good, but very specific to imx, not too much general information
<ssvb>
jemk: experiments show that SFWDLY/SFBDLY bits act like a more fine-grained SDPHASE, with steps roughly around 4-6 degrees instead of 18 degrees for SDPHASE
Fusing has joined #linux-sunxi
<ssvb>
jemk: changing MFWDLY/MFBDLY for the byte lane MSDLLs does not seem to have any effect, but I still need to double check this
pseudomind has quit [Quit: pseudomind]
<ssvb>
jemk: I just wonder if these MFWDLY/MFBDLY bits were supposed to be there for write leveling
<jemk>
ssvb: i don't think so, they are for fine tuning the dll
<jemk>
ssvb: but it might be the only way because we really lack write leveling support
<jemk>
ssvb: the effect of sfwdly and similar is described pretty good in rk30xx manual under ddr phy - feedback trim
<ssvb>
jemk: yes, that's why I wanted to check them
<ssvb>
jemk: there are also knobs, controlling delays for the individual bits
<ssvb>
jemk: about the settings in u-boot, we can also automatically find and patch the dram configuration block in the spl directly on the sd card
<ssvb>
jemk: but of course only if we are pretty sure these settings are workable and the system is going to boot :)
<jemk>
ssvb: my initial tests with tpr3 i did with fel boot and patched spl
<ssvb>
jemk: another method would be patching u-boot to get these settings from the serial console and use the PC to control the whole process
geecko has joined #linux-sunxi
<ssvb>
jemk: but then again, it would be very nice to have a software controlled power supply to interrupt power at will
<ssvb>
jemk: or some watchdog hacks, setting it in the u-boot, then passing it to the kernel and ending up in the userland
<jemk>
ssvb: lab power supply ;) i also tried to port memtester to u-boot, but gave up again
<jemk>
ssvb: we don't need a full memtester, only some fast detection of obvious problems
<jemk>
ssvb: the full test is only needed to finally verify the found possibilities
<jemk>
ssvb: maybe even the build in mtest in u-boot could work, i totally missed that...
<ssvb>
jemk: one problem with just memtester is that it appears to be only effective with the additional pressure on ram from mali
<ssvb>
jemk: remove the mali part, and memtester will run happily without spotting anything
<ssvb>
jemk: u-boot is interesting for the hardware assisted training, utilizing the features of the memory controller
<jemk>
ssvb: just some silly idea, but maybe stressing mali only loads dcdc3 more and thus the dram controller voltage isn't that high anymore
<ssvb>
jemk: do you mean that mali is powered from dcdc3 (I don't know this myself)?
<ssvb>
jemk: in any case, one test to verify this might be the use of some computationally heavy shaders instead of memory intensive ones
<ijc>
maz_: I've just pushed git://gitorious.org/ijc/u-boot.git sunxi-mainlining-v3-pre, which is close to what I hope to post, just waiting for a couple more fixes to be picked up into u-boot-sunxi.git. Your PSCI seems to have rebased nicely onto it if I skip the mmc stuff from your side which was done differently in sunxi.git
<jemk>
ssvb: yes, nearly everything digital logic except cpu is powered from dcdc3. i'll try to measure it now
<ssvb>
jemk: thanks, that would be very interesting
<ssvb>
jemk: in any case the dcdc3 voltage also clearly plays some role, but I still was getting memtester memory corruption reports at 480MHz dram clock speed no matter how high was the dcdc3 voltage
<ssvb>
jemk: with low dcdc3 voltage it was deadlocking, so that's a somewhat distinct symptom