<willmore>
_mamalala, I just read the thread the tkaiser posted. Wow, that was quite the chase. I have one of the little 2MP cameras on the way. Sounds like it'll work without any issues on my Opi1. I made sure it was the one with the adapter board.
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
lennyraposo has quit [Quit: Leaving.]
arnd has quit [Ping timeout: 258 seconds]
popolon has quit [Quit: WeeChat 1.4]
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Client Quit]
arnd has joined #linux-sunxi
perr has joined #linux-sunxi
perr has joined #linux-sunxi
perr has quit [Changing host]
ninolein_ has quit [Ping timeout: 255 seconds]
ninolein has joined #linux-sunxi
curtis22 has quit [Quit: Leaving]
perr has quit [Quit: Leaving]
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
willmore has quit [Ping timeout: 250 seconds]
willmore has joined #linux-sunxi
pg12 has quit [Ping timeout: 244 seconds]
pg12 has joined #linux-sunxi
_mamalala_ has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
_mamalala has quit [Ping timeout: 264 seconds]
perr has quit [Remote host closed the connection]
andor2007 has quit [Ping timeout: 240 seconds]
gzamboni has joined #linux-sunxi
petr has quit [Ping timeout: 265 seconds]
petr has joined #linux-sunxi
IgorPec has joined #linux-sunxi
tkaiser has joined #linux-sunxi
perr has joined #linux-sunxi
perr has quit [Client Quit]
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has joined #linux-sunxi
foxx_ has joined #linux-sunxi
mosajjal has joined #linux-sunxi
merbanan has quit [Ping timeout: 260 seconds]
IgorPec has quit [Ping timeout: 276 seconds]
JohnDoe_71Rus has joined #linux-sunxi
merbanan has joined #linux-sunxi
fire219 has quit [Read error: Connection reset by peer]
<tkaiser>
But I fear that the average Pine64 user won't benefit from. Comparing numbers without meaning is more easy than thinking about what's happening and how real-world performance might be improved :)
<jelly>
so you discovered the cpu can be a bottleneck, iperf is just doing what it does everywhere
perr_ has joined #linux-sunxi
perr has quit [Ping timeout: 255 seconds]
<lamer14724538135>
jelly: CPU is a bottleneck in one direction with iperf/iperf3, it's the reason why Pine64 maxes out at 920 MHz in one direction at 1152 MHz. With 480 MHz it's just 630 Mbits/sec and am now testing with 1296 MHz
<lamer14724538135>
And this only applies to iperf/iperf3 binaries shipped with Xenial. Those for Debian Jessie for example might perform worse while a Gentoo installation (build from scratch with optimised settings) will not be bottlenecked.
<lamer14724538135>
Add to this different cpufreq governor behaviour and throttling and you get different 'network throughput' only caused by CPU clockspeed all the time
<jelly>
I mean, this is nothing new, same thing happened with gigabit at P2-P3 time 15+ years back
<lamer14724538135>
True, but people always forget about this and use inapproriate tools in an inappropriate mode (passive benchmarking)
* jelly
is amused at apparent surprise that kernel and build time settings sometimes matter
Mr__Anderson has quit [Remote host closed the connection]
dearfibonacci has joined #linux-sunxi
<mripard>
speakman: not with 4.6
tkaiser has joined #linux-sunxi
<speakman>
ok :(
<avph>
Hi. I'm trying to get flashrom working on spidev on a a20 device with linux 4.6.
<avph>
Now the kernel gives me this: "spidev spi0.0: SPI transfer failed: -22
<avph>
spi_master spi0: failed to transfer one message from queue
andor2007 has joined #linux-sunxi
nikre has joined #linux-sunxi
leio has quit [Ping timeout: 244 seconds]
leio has joined #linux-sunxi
<nikre>
i get random freezes on the client:openelec-kodi-tvheadendHtspClient and server is armbian4.xKernel-tvheadendBackEnd-usbDvbS2. jernej said it must be related to the cedarx. is there anything i can do to improve client performance? a compilation parameter?
<ssvb>
avph: you may also try to program your spi flash chip using sunxi-fel as described on this wiki page
<ssvb>
avph: btw, mripard is the author of the kernel spi driver, if you want this crap to be fixed in the kernel then he is most likely the best person to ping
<avph>
ok thanks. will look into it
perr has quit [Remote host closed the connection]
foxx__ has quit [Quit: terminated!]
<Net147>
mripard: when I disable framebuffer in U-Boot, then enable PH8 (232) using /sys/class/gpio I notice the LCD turns on but when I try to do the same as part of devicetree it doesn't turn on - http://pastebin.com/raw/AKdCkAJM
foxx__ has joined #linux-sunxi
<Net147>
mripard: am I using enable-gpios property of simple-panel driver incorrectly?
<jonkerj>
probably significantly slower than native SPI
premoboss has joined #linux-sunxi
<buZz>
lol, about SPI
<buZz>
11:08:14 < azonenberg> meanwhile, i can't ever order miso soup at a Japanese restaurant
<buZz>
11:08:17 < azonenberg> without thinking about SPI
<buZz>
11:10:27 < cousteau> lol
<buZz>
11:10:57 < cousteau> nerdy Japanese restaurants should also have MOSI soup
<jonkerj>
rofl
nikre has quit [Read error: Connection reset by peer]
Da_Coynul has joined #linux-sunxi
<ssvb>
jonkerj: the spi controller is really simple, just the current implementation leaves a lot to be desired and the device tree adds a bit of extra annoyances
premoboss has quit [Ping timeout: 265 seconds]
<ssvb>
jonkerj: I did not mean to discourage avph, one definitely can use spi with a little bit of efforts
<avph>
I have other ways to flash spi flash but I though a20 would be a nice fast way to do it
OverCR1 has quit [Read error: Connection reset by peer]
Mr__Anderson1 has quit [Ping timeout: 258 seconds]
slaaneshLT has joined #linux-sunxi
slaaneshLT has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
paulk-collins has quit [Quit: Leaving]
instance666 has quit [Quit: Page closed]
NiteHawk has quit [Ping timeout: 244 seconds]
NiteHawk has joined #linux-sunxi
NiteHawk has quit [Changing host]
NiteHawk has joined #linux-sunxi
mosterta has joined #linux-sunxi
iamfrankenstein1 has quit [Quit: iamfrankenstein1]
Mr__Anderson has quit [Remote host closed the connection]
jbrown has quit [Ping timeout: 260 seconds]
mosajjal has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
OverCR has quit [Read error: Connection reset by peer]
mosterta has quit [Ping timeout: 265 seconds]
FergusL has joined #linux-sunxi
<FergusL>
anyone patched H3 kernel with realtime? or even further with Xenomai?
<tkaiser>
longsleep: I was wrong since applying your settings led to a huge variation in results and I tested not long enough. Corrected that here and there but think still that the most important fix to solve the 'general' GbE speed issue with A64 (and any other sunxi SoC) is replacing ondemand cpufreq governor with interactive or performance (or schedutil starting with 4.7 then)