2016-09-19

<montjoie> anyway thanks tkaiser for founding this problem
<montjoie> but just moving it a few lines before cause that drop, it is strange
<montjoie> the line touched bythe patch si for BQL, and according to my readings, BQL drop perf for gaining latency
<tkaiser> montjoie: But it's faster if the reboots caused by panic are also taken into account! ;)
<montjoie> so the patch made loosing 70Mo/s:(
<tkaiser> montjoie: In the upper half, OPi Plus is sending and gets pretty stable 875 Mbits/sec, in the lower half we had 940 Mbits/sec plus kernel panic after a couple of seconds before
<tkaiser> montjoie: This is the view from the other side: http://pastebin.com/XxjLq04g
<tkaiser> montjoie: Will post a paste soon, let's wait a few minutes more
<montjoie> tkaiser: strange that that small modification cause perf downgrade
<tkaiser> montjoie: Still no panic, but performance degraded and a lot of retries.
<tkaiser> montjoie: Now testing the other direction. Let's wait... :)
<tkaiser> montjoie: Tested 5 minutes in the direction that was not affected first: 877 Mbits/sec
<montjoie> ok thanks
<tkaiser> montjoie: Get back to you in half an hour (lunch first).
<montjoie> tkaiser: could you try https://bpaste.net/show/2d99e6b865c6 that for fixing the problem ?

2016-09-17

<montjoie> no
<tkaiser> montjoie: Do you have another machine that maxes out a GbE line? Able to get close to 940 Mbits/sec?
<montjoie> first I need to reproduce the problem
<tkaiser> montjoie: If you fixed something, drop me a note when you need further testing. My Armbian build system currently uses your Github repo so I can almost immediately test things :)
<montjoie> mmh certainly a bug in my bql handling
<montjoie> didnt see it
<montjoie> do you have some stack trace ?
<tkaiser> montjoie: Yeah, generating high network load with your driver H3 devices can be rebooted ;)
<montjoie> tkaiser: kernel panic ?
<tkaiser> montjoie: s/written/read/
<tkaiser> montjoie: Your driver (kernel panic again when data has been written from OPi): http://pasteboard.co/49e8I79wJ.png. And that's BSP kernel with same setup: http://pasteboard.co/49d3lab0H.png

2016-09-16

<tkaiser> montjoie: Have to leave/run (out for some beers). Maybe there's something interesting: http://sprunge.us/fRiD
<tkaiser> montjoie: PHY on OPi Plus 2E can not be forced to Fast Ethernet via ethtool: http://pastebin.com/gdFt0Aqn
<tkaiser> montjoie: I'm testing against my usual 'test gear', MacBook Pro running OS X able to exceed 940 Mbits/sec.
<tkaiser> montjoie: 10 minutes in the opposite direction: http://pastebin.com/CKRHRuxd
<jonkerj> montjoie: both opi's are still happy
<tkaiser> montjoie: Next attempt lastest way longer: http://pastebin.com/jK0dxvFF
<montjoie> jelle: iperf is a good start, then plug/unplug ifconfig down/up
<tkaiser> montjoie: Just wanted to point out that I use now a device with 2 GB DRAM -- sometimes this might make a difference: https://github.com/ssvb/lima-memtester/issues/2
<tkaiser> montjoie: OPi Plus 2E is like BPi M2+ with one USB port and one led more (and differences regarding WiFi/BT). All pin mapping for everything else are the same
<jelle> montjoie: hmm what should I test with ethernet?
<montjoie> tkaiser: i didnt see any opi plus 2e DTS anywhere, thanks for the test
<tkaiser> montjoie: Don't have access to BPi M2+ currently and to no other H3 board with GbE and just 1 GB DRAM (just in case whether this makes a difference)
<tkaiser> montjoie: This is on a 2 GB OPi Plus 2E running with DT stuff for OPi Plus (didn't manage to get the PHY to work when using BPi M2+ settings)
<tkaiser> montjoie: http://pastebin.com/84zHgLc5
<tkaiser> montjoie: I'm in. But I had to use config for OPi Plus (testing on OPi Plus 2E anyway ;)
<tkaiser> montjoie: Just a moment, maybe my mistake
<tkaiser> montjoie: Nope, also no PHY leds lighting
<tkaiser> montjoie: ok, will give it a try again :)
<montjoie> tkaiser: fixed on github
<montjoie> it should fail for not having phy-handle
<montjoie> strange that v4 work on it
<tkaiser> montjoie: OK, since currently it's like this: http://pastebin.com/3uLFXj2L
<montjoie> tkaiser: for Banana Pi M2+ I will update it
<montjoie> perhaps I forgot to change them
<montjoie> tkaiser: I need to check the DT
<tkaiser> montjoie: Should your v4 work on a Banana Pi M2+ or OPi Plus 2E?
<montjoie> one day I will release all my cfengine/monitoring stuff
<jonkerj> montjoie: tnx
<montjoie> jonkerj: cfengine is beter than puppet (troll started)
<jonkerj> montjoie: applies, compiles, boots, loads, works on opi-pc
<montjoie> thanks jonkerj
<jonkerj> montjoie: applies, compiles, boots, loads, works on opi+
<montjoie> I need to check that I didnt forget any comment
<jonkerj> montjoie: I will try them at once
<jelle> montjoie: cool
<montjoie> jonkerj: jelle I have just updated the V4 with latest changes
<jonkerj> montjoie: I've (successfully) tested v4 on my opi+ and opi-pc
<apritzel> jonkerj, montjoie: I think it's time to get it in to get some more testing
<montjoie> jonkerj: I need to test V4 on all my SoCs

2016-09-15

<montjoie> tkaiser: I think EMAC will be the same as A20 but Crypto seems like H3/A64

2016-09-14

<montjoie> thanks plaes
<montjoie> I need to add a precommithook with some spell check
<montjoie> I need also typo reporting:)
<plaes> montjoie: I hope you don't mind reporting the typos?
<montjoie> I have published the latest version of emac driver (https://github.com/montjoie/linux/tree/sun8i-emac-wip-v4) tester wanted:)

2016-09-09

<montjoie> apritzel: v3 sent:)
<tkaiser> montjoie: I had some hope GbE throughput would increase with higher CPU clockspeeds. But it's still 470 Mbits/sec regardless whether I clock with 408 or 854 MHz in TX direction. In the other direction I can not test since I only have a board here now that shows the GbE issue
<montjoie> I think I will add the pm_runtime patch as RFC
<apritzel> montjoie: off-tree the testing exposure is much lower
<apritzel> montjoie: if your driver works, it should be merged, we can make it fancy later
<apritzel> montjoie: I really get annoyed by everyone asking you to add featureX in your driver
<montjoie> apritzel: I am blocked by pm_runtime:)
<apritzel> montjoie: if you are blocked on this, just send out what you have and don't mention big endian ;-)
<apritzel> montjoie: yeah, sorry, I didn't have time for that yet (because I have to find my big endian setup first again)
<montjoie> apritzel could you try your big endian kernel with sun8i-emac ?

2016-09-05

<ssvb> ganbold, montjoie: it's a bit old, but still - https://irclog.whitequark.org/linux-sunxi/2013-03-29#3397649
<ganbold> montjoie: does it look any good? http://pastebin.ca/3711395 in FreeBSD
<montjoie> and perhap the bench was done with an old version
<montjoie> ganbold: I need to send the last version for mainline
<montjoie> ganbold: someone did it http://www.cacert.at/cgi-bin/rngresults
<ganbold> montjoie: do you have test numbers for RNG for A10/A20?

2016-09-03

<apritzel> KotCzarny: I was halfway through with it in January, but stopped this when montjoie got something working
<apritzel> Budovi: montjoie's driver (in a64-v5) is pretty good these days

2016-09-02

<tkaiser> montjoie: in other words, cpufreq is part of the problem when testing with iperf/iperf3
<tkaiser> montjoie: iperf/iperf3 are both CPU bound. But users using your driver with Pine64 running on 408 MHz get way better speeds than with OS images from pine64.pro: http://forum.pine64.org/showthread.php?tid=2078&pid=19025#pid19025
<montjoie> basic iperf is stable so it is a good indication, but I want to know if I can get better
<apritzel> montjoie: you mean tweak your benchmark setup to get better numbers? ;-)
<montjoie> I need to read tkaiser post on ethernet perf:) for better bench
<montjoie> good
<jmcneill> how is performance these days montjoie?
<apritzel> montjoie: emac-wip-v3?
<montjoie> apritzel: on my github
<apritzel> montjoie: Sure (but only later tonight). Where can I find the latest and greatest version of your driver?
<montjoie> apritzel: could you test as you proposed my emac driver on a big endian kernel ?

2016-09-01

<_mamalala> montjoie: ah, ok
<montjoie> the table are for sun4i-ss (A20 and co)
<montjoie> _mamalala: the crypto engine in A64/H3/A83t is slow for the moment (according to my latest test)
<willmore> I was wondering why you describing montjoie as 'brand new unopened'.
<KotCzarny> and of course new battery, but that's obvious for almost any device, even 'brand new unopened'montjoie's page yet

2016-08-28

<tkaiser> ssvb: I will wait a bit, just tested around with 4.7. IIRC montjoie was not happy with GbE throughput testing on A64 but that's most probably just due to CPU cores running at 408 MHz (iperf is CPU bound and acts single-threaded in one direction)

2016-08-23

<tkaiser> _mamalala_: montjoie and others worked on Ethernet. Still not perfect but for most if not all use cases already sufficient (especially with Fast Ethernet / internal PHY). I'm running 4.7.2 now with Ethernet and WiFi working on OPi Lite, NanoPi NEO and M1. Martin Ayotte managed to get device tree overlays working so you can even use stuff like SPI or I2C already with H3 boards and 4.x
<montjoie> 3.4.1xx, yesterday I check the kernel version of my phone... 3.4.5, ouch such security

2016-08-17

<montjoie> MoeIcenowy: yes:)
<MoeIcenowy> montjoie: what's 504i?!
<montjoie> apritzel: when adding sun504i, you could add a patch for adding N: sun504i to ARM/Allwinner sunXi SoC support in MAINTAINERS
<montjoie> no only the arm64: Allwinner A64 support​ (v4)
<MoeIcenowy> montjoie: the SCPI RFC PATCH series?
<montjoie> no latest a64 patch sent for mainlining
<MoeIcenowy> montjoie: which series do you mean?
<montjoie> apritzel: so it is extremly strange that i got MMC working stable with your A64 series only ...

2016-08-16

<apritzel1> montjoie: if you enable it, it gets detected and shows the partitions, but hangs rather quickly
<apritzel1> montjoie: and then still eMMC will not work properly
<apritzel1> montjoie: for MMC to work you need all the new series: A64 (with BPi .dts), MMC firmware clocks and updated ATF
<montjoie> apritzel, i booted my bpi64 with your patch and MMC worked, but now never bpim64 nor pine64 have mmc with it, normal ?

2016-08-15

<montjoie> anyone with a H3 running a mainline kernel with gigabit EMAC ? (and with iperf stat)
<montjoie> anyone with a bpim2+ running a mainline kernel with EMAC ? I got only 330Mbit/s
<apritzel> montjoie: btw: I was seeing that with the "upstream" A64 firmware we end up with a 200 MHz AHB2 clock, whereas the recommended speed is 300 MHz (the BSP package uses this as well)
<apritzel> montjoie: sure, thanks!
<montjoie> apritzel: successsfully tested your A64 patchs with emac, do you want some Tested-By ?

2016-08-14

<montjoie> wens: adding pm_runtime as mripard suggested is a major change (lots of comments to come)
<montjoie> luoyi: dont think so

2016-08-11

<montjoie> same question forall other sunxi driver
<montjoie> mripard: wens do you think adding linux-sunxi as list in MAINTAINERS for sun8i-emac is good ?
<montjoie> KotCzarny: just basic bench done for the moment
<montjoie> "good"
<montjoie> for the crypto engine(H3/A64) i have four stream so AES/4*4 its good
<montjoie> if i do an ipsec tunnel with that, it is four time slower, not acceptable
<montjoie> for having cpu free, I accept a decrease of 10/20% perf, not more
<montjoie> MoeIcenowy: for the moment both:) I need to work harder, but all hash have perf/10 and AES perf/4 (comparing with software)
<MoeIcenowy> montjoie: because of hardware limit
<montjoie> for the moment, the crypo engine of H3/A83T/A64 are also not so fast

2016-08-09

<montjoie> apritzel1: thanks I just received my bpi M64 so I will test it
<apritzel> montjoie: not really stress tested, but I could ssh in and did some apt-get without issues
<apritzel> montjoie: As I think you were interested in this: Ethernet seems to work out of the box on the BananaPi M64

2016-08-08

<montjoie> disappointement!, hardware spinlock are not used for "speeding" spinlock
<montjoie> I survived 8 years with only one core:) (3 damaged out of 4)
<apritzel> montjoie: make -j50 on a Cavium box isn't too bad ;-)
<montjoie> cross compile is the fatest way to compile kernel

2016-08-04

<montjoie> HdeGoede sent me a patch for adding ethernet*, so my v3 have it
<jonkerj> using 2016.05 and 4.7 with montjoie's patches that was not the case on my board, wens
<montjoie> derRichard: http://linux-sunxi.org/SID_Register_Guide but didnt know if there are enought random for using as serial

2016-08-03

<montjoie> foxx_: thanks
<foxx_> montjoie: rolled back sun8i-emac.c changes - everything's ok. looks like it was uboot problem
<montjoie> yeah, when benching my opipc (100M) I stuck my connexion...
<montjoie> perhaps I am stuck at 511Mb/s for TX
<KotCzarny> montjoie: you need to break the board in some magical way
<montjoie> and still didnt understand why you have better transfer speed than me:)
<foxx_> montjoie: had no time to check yet, sorry
<montjoie> foxx_: does the reollback changed something ?

2016-08-02

<willmore> montjoie, okay, thanks. I have a Pine64 2GB that I can test gig E on if you'd like another data point.
<montjoie> willmore: both, a64 and h3 (and a83t)
<willmore> montjoie, does your driver support the A64 or just the H3?
<foxx_> montjoie: ~650mbit/s on both boards for me
<montjoie> foxx_: not enought for TX for me, only 500mb/s but got strange unreproductible iperf up to 800
<foxx_> montjoie: it works :) and i can rollback of course
<montjoie> if you could rollback the sun8i-emac.c for testing:)
<montjoie> foxx_: so it works now ?
<foxx_> montjoie: nothing
<montjoie> foxx_: nothing usefull in dmesg ?
<foxx_> montjoie: also i noticed that if i plug 'working' board in 100mbit switch it also won't work correctly
<montjoie> BSP dont support ethtool stats
<montjoie> foxx 4.7+
<foxx_> montjoie: on which environment? 3.10 bsp or 4.7+ apritzel's?
<montjoie> foxx could you give em ethtool -S eth0 for it ?
<foxx_> montjoie: be patient, it's a long story. first, i have 2 pine64 boards and i prepared & duplicated sdcard images for both of them using dd, so both they have the exact copy of software
<montjoie> foxx_: what is the exact problem with your pine64 ?
<MoeIcenowy> montjoie, apritzel: have you noticed this condition?
<montjoie> jonkerj: thanks for the test
<jonkerj> montjoie: I've made a (small) additional patch to make v3 work on 4.7 (undo CCU), and it seems to work (load, ifup, ping) fine on my opi+
<montjoie> wens: thanks
<montjoie> wens so just adding a syscon node and regmap with it ? like https://bpaste.net/show/c56ae48caaec
<jonkerj> montjoie @ v3: great news! I'm going to try this on my Opi+ right away
<montjoie> wens: followinf mripard proposal of using a syscon driver, do you think adding a mfd driver with helpers like "set_rgmii/set_mii/power_int_phy" could be better ?
<montjoie> cnxsoft: no, need to fix all comment that I get on v2
<cnxsoft> Great! montjoie. Does that mean Allwinner H3 Ethernet support in the next Linux 4.8 release then?

2016-07-29

<apritzel> montjoie: oh, indeed, I haven't actually checked for other users
<montjoie> apritzel: due to number of users of cpu_to_le32(BIT(x)), perhaps sending a patch of LE32_BIT() could be done:)
<montjoie> apritzel: for v3 the number of comment change is more than code change:)
<apritzel> montjoie: yeah, good point, prevents the next one from stumbling over it ;-)
<montjoie> apritzel: added a comment for it:)
<apritzel> montjoie: yes, otherwise we clobber the possible error code too early
<montjoie> apritzel: oh you do it but after dma_mapping_error
<montjoie> apritzel: dmap_map_xxx does not need to have endianess function on their return right ?
<montjoie> I need to publish my v3 soon
<apritzel> montjoie: I used this to test a similar fix for the MMC driver (which also uses DMA descriptors) on my BPi-M1
<apritzel> montjoie: I think I have a big-endian ARMv7 initrd somewhere, in case you need this
<montjoie> apritzel: thanks for the endianess, I will test it this week end

2016-07-26

<montjoie> the v2 was sent for review one week ago, and I have just started to implement fix from reviewers
<montjoie> apart from the bug I just found:)
<montjoie> the v2 is the very latest, no real commit since it
<jonkerj> montjoie: is there a public accessable version of your latest patch, other than the github branch v2?
<montjoie> just found a bug, now 700Mb/s is stable for reception
<montjoie> :)
<jonkerj> montjoie: boots, works, pings
<jonkerj> montjoie: same error
<montjoie> yes
<montjoie> jonkerj: try getting mine from my github
<montjoie> jonkerj: which version of my patch are you using ?
<montjoie> jonkerj: strange that it can probe PHY without having request region, does emac node is present twice ?
<jonkerj> I'm trying to run 4.7 with montjoie's emac patches on my h3 opi+

2016-07-25

<montjoie> I get some boost by not using cryptoengine pump and being syncchronous but still unperforment
<montjoie> interesting that perf is near the same
<montjoie> for sha512 I got 2462 vs 1720
<montjoie> opipc
<apritzel> montjoie: on which board/SoC?
<montjoie> something is wron
<montjoie> ouch sha1 generic 12500 op/s, sha1 with CE 1750 :'(

2016-07-21

<TheLinuxBug> montjoie: ^
<montjoie> TheLinuxBug: you bench which soC ?
<montjoie> mripard: wens So if I have understand, in sun8i-h3 I need to add an "ephy" node (with syscon clock/reset)?
<montjoie> mripard: so you want that I rollback to standalone wens phy driver ?

2016-07-20

<apritzel> this (a64-v5) is with montjoie 2nd version of the driver, which should improve performance thanks to the NAPI implementation
<apritzel> montjoie has some numbers on the sun8i-emac wiki page

2016-07-19

<MoeIcenowy> montjoie: thanks!
<montjoie> just updated sun8i-emac, will send v2 soon

2016-07-17

<KotCzarny> dont know which one dabbled in a13. wens? apritzel? montjoie?

2016-07-16

<apritzel> MoeIcenowy: EMAC on Pine64> where do you have problems? You need montjoie's latest driver, the DT bits from a64-v5 and need to turn on DC1SW in the PMIC
<smooker> montjoie: played with ethtool... some packets passed ;)
<montjoie> smooker: yes I will upload it
<smooker> montjoie: mai i ask you for precompiled kernel and a dtb for orange pi pc (just to give it a try) ?
<smooker> montjoie: checked with 2 cables. green led is for activity and is constantly on
<montjoie> smooker: check with another cable/power source
<smooker> montjoie: tried with cable to the laptop insted of the switch - same behaviour
<smooker> montjoie: green led is constantly on, orange on i off
<smooker> montjoie: │ │ < > Allwinner sun8i EMAC support │ │
<smooker> montjoie: got only lo0 ;)
<smooker> montjoie: compiling now.
<smooker> montjoie: 10x. will pull it afer it finishes cloning
<montjoie> smooker: commit done
<smooker> montjoie: you will commit now ?
<smooker> montjoie: remote: Counting objects: 4799725, done.
<montjoie> I have just to commit a little fix from this week
<montjoie> and you use an orange pi 2 ?
<montjoie> I think davem is not the good tree for testing first, could you try mine ?
<smooker> montjoie: still reading allwinner h3 datasheet. can you give me a clue .. ? ;)
<smooker> montjoie: nope. it does not light up leds. i'm not sure if it's ok this way with CCU.
<montjoie> smooker: I have just see your email, so now it works ?
<smooker> montjoie: hi
<montjoie> smooker: need more details

2016-07-15

<wens> montjoie: no, i haven't started it yet
<montjoie> wens: I believed you started it
<wens> montjoie: haven't started working on a83t psci
<montjoie> Does PSCI/SMP for A83T is usuable ?
<montjoie> just added a83t to the status matrix

2016-07-10

<montjoie> KotCzarny: right and one week that I said that i need to add that line
<KotCzarny> montjoie: no h8/a83t in the table
<imcsk8> montjoie: thanks!
<montjoie> imcsk8: see the feature matrix and get the highest kernel mentionned in it (http://linux-sunxi.org/Linux_mainlining_effort)

2016-07-09

<montjoie> so Rambler44 you just need to see aes in /proc/crypto and using AF_ALG or cryptodev for having hw acceleration in openssl
<montjoie> BSP kernel have also crypto device driver
<montjoie> oups I dont see you use 3.4, all speak for mainline...
<montjoie> Rambler44: see sunxi.montjoie.ovh for all ciphers detail
<montjoie> Rambler44: hardware AES via crypto device is under work

2016-07-06

<montjoie> and for valentine day, we can replace all by small to big pink heart according to love(work) for each
<buZz> montjoie: why the expression? :)
<montjoie> I love colors!!
<stephan> montjoie, I took the udelay from the linux-sunxi 3.4 driver. I'm not sure, if this is an hardware issue.
<montjoie> and uint32_t must be replaced by u32
<montjoie> why 100 and not 50. perhaps a write/read memory barrier could repalce it
<montjoie> _stephan, you need to explain the udelay(100)
<apritzel> montjoie: that would require to cleverly group the SoC rows, which eventually is a NP-complete problem? ;-)
<mripard> montjoie: then instead of "?", simply put the name of the SoC it shares the block with
<akaWolf> montjoie: I saw, thanks, WIP isnt very describe something
<montjoie> when possible
<montjoie> so for example make a black border color between emac for h3/a64
<montjoie> mripard: we dont have the information "same with what ?"
<montjoie> apritzel1: mripard for the feature matrix, do you think adding border color for visual "same IP block" could be usefull ?
<montjoie> akaWolf: you can check the wonderfull matrix at http://linux-sunxi.org/Linux_mainlining_effort for DRM you can see WIP

2016-07-01

<mripard> montjoie: we should probably order the fields alphabetically
<MoeIcenowy> montjoie: sorry...
<montjoie> MoeIcenowy: your changelog are bery bad, always the same
<MoeIcenowy> montjoie: I think the answer should be "Yes"
<montjoie> wens: does RSB column could be usefull ?
<montjoie> MoeIcenowy: A33 doesnt have spinlock/msgbox so I put them NA
<montjoie> if not all piece of code is mainlined, I think it need to be orange
<montjoie> yeah blanck is good for me
<MoeIcenowy> montjoie: how to indicate "No such feature"?
<montjoie> ok I put all in red
<montjoie> I believe to have seen some i2c/audio patch from you
<wens> montjoie: what audio?
<montjoie> KotCzarny: I fix it
<montjoie> i dont know if wens work on audio is for that
<KotCzarny> montjoie, then i guess 'unknown' is better than 'todo'
<montjoie> it is a "wiki todo"
<montjoie> KotCzarny I dont know the status
<apritzel> wens: montjoie: I added some kind of "local footnote" to the table (explaining slow MMC on A64)

2016-06-30

<montjoie> since I own them
<montjoie> ssvb: I will add A20 and A83T tonight
<montjoie> I have added a column when somone worked on something
<montjoie> wens: perhaps pinctrl could be non-green in thefuture