<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: 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 ;)
<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: 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 ?
<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
<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+
<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?
<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