narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki - ml - Publicly Logged on
Darkmatter66 has quit [Ping timeout: 272 seconds]
Darkmatter66 has joined #linux-amlogic
Barada has joined #linux-amlogic
Darkmatter66 has quit [Ping timeout: 245 seconds]
vagrantc has quit [Ping timeout: 252 seconds]
Darkmatter66 has joined #linux-amlogic
<narmstrong> BlueMatt: can you log the changes between 4.19.57 and 4.19.68 ?
<narmstrong> f47f68cc9d33 net: stmmac: Re-work the queue selection for TSO packets
<narmstrong> 41864adfee2e net: stmmac: sun8i: force select external PHY when no internal one
<narmstrong> df6680de7a20 net: stmmac: dwmac4/5: Clear unused address entries
<narmstrong> 50331c64f3dd net: stmmac: modify default value of tx-frames
<narmstrong> 1a0a837afc41 net: stmmac: dwmac4: fix flow control issue
<narmstrong> d3969670cb5a net: stmmac: dwmac1000: Clear unused address entries
<narmstrong> 9b7b0aab4750 net: stmmac: set IC bit when transmitting frames with HW timestamp
<narmstrong> a373bf728188 net: stmmac: fixed new system time seconds value calculation
<narmstrong> either you test at each commit, or you git bisect from 4.19.57 to 4.19.68
ldevulder__ is now known as ldevulder
Darkmatter66 has quit [Ping timeout: 245 seconds]
Darkmatter66 has joined #linux-amlogic
yann has joined #linux-amlogic
vdehors has joined #linux-amlogic
sputnik_ has quit [Ping timeout: 244 seconds]
Darkmatter66 has quit [Ping timeout: 245 seconds]
Darkmatter66 has joined #linux-amlogic
random_yanek has quit [Ping timeout: 246 seconds]
random_yanek has joined #linux-amlogic
Barada has quit [Quit: Barada]
yann has quit [Ping timeout: 272 seconds]
vagrantc has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
Darkmatter66 has quit [Ping timeout: 248 seconds]
Darkmatter66 has joined #linux-amlogic
yann has joined #linux-amlogic
<BlueMatt> narmstrong: sadly it takes a day or two before I see the timeout :/
<BlueMatt> I can maybe start the process this weekend on one of my spare odroid-c2s, but its pretty reliable after a few days with maybe 10M/s of traffic it will hang
sgnut has joined #linux-amlogic
<narmstrong> BlueMatt: we used a lot iperf3 to trigger issues in the ethmac, can you try tweaking options to make it more agressive and trigger the timeout ?
ldevulder_ has joined #linux-amlogic
ldevulder has quit [Ping timeout: 245 seconds]
<repk> isn't it weird that pci-meson's way of deasserting PERST is with "gpiod_set_value_cansleep(mp->reset_gpio, 1);" ?
<sgnut> someone from the #odroid channel has explained me that cpufreq governor is not available for mainline kernel yet. Is this correct? I have just compiled a 5.2.11 for my odroid-c2 soc and I discovered that I haven't any entry in /sys regarding cpufreq
<xdarklight> repk: it's likely that someone screwed up the GPIO polarity in .dts and "fixed" that by swapping the polarity in the driver again to make it work
<xdarklight> sgnut: yes, unfortunately Odroid-C2's SCPI (system control processor interface) firmware (which is responsible for frequency CPU scaling) reports frequencies as supported which don't work if all 4 CPU cores are enabled -> this leads to system hangs
<xdarklight> sgnut: my personal opinion is that it's a bug in the firmware. if I remember correctly there's a setting in boot.ini to set the number of active CPU cores - the firmware should honor that
<sgnut> xdarklight: yes there is a maxcpus directive. So, is there any plan to port the cpufreq governor to the mainline kernel in the same manner that currently works for other versions (e.g. 3.4). I suppose that such kernel versions use some kind of tricks, like the one of the maxcpus
<xdarklight> sgnut: I don't know of any plans to add support at the moment because this problem is limited to the SCPI firmware that's shipped in Odroid-C2's u-boot. no other Amlogic board (that I know of) has this firmware issue
<sgnut> xdarklight: does hardkernel considered any option to upgrade the firmware?
<xdarklight> sgnut: I think they are the ones who changed the firmware. (it's been a while, but I think early u-boot revisions didn't have this problem, it only appeared after HardKernel tried to do some "overclocking" optimizations)
<sgnut> xdarklight: mmm so how the current official versions don't suffer such problem? Just by appling some tricks like the one that we commented (maxcpus)?
<xdarklight> sgnut: I think the official firmware "hardcodes" maxcpus to 4 and so they only report the frequencies which are supported with that core count. I don't know if there's an actual maxcpus check in the firmware or if it's due to them hardcoding maxcpus (so they can also hardcode all other values)
Darkmatter66 has quit [Quit: ZNC 1.6.5+deb1+deb9u2 -]
Darkmatter66 has joined #linux-amlogic
<xdarklight> sgnut: it's been 2.5 years where Neil disabled DVFS and I even informed the HardKernel guys about this issue: (I didn't ping them again because I don't have an Odroid-C2 myself so I cannot do any testing if they ask for it)
<xdarklight> sgnut: more information on that topic:
<xdarklight> sgnut: maybe you ping the HardKernel guys about this again and ask them if they can come up with a solution for mainline Linux? enabling CPU frequency scaling in Linux will then be super easy: just revert the meson-gxbb-odroidc2.dts part from
<sgnut> xdarklight: do you think that it could be possible that users upgrade the firmware. Isn't require some kind of hardware manipulation?
<xdarklight> sgnut: it's part of the bootloader binary in the first sectors of eMMC / SD card. so it can be upgraded
<sgnut> xdarklight: ohhh you mean the u-boot that I changed just by using the dd command. So. it seems something easy. I don't understand why hardkernel has not provided a solution
<xdarklight> sgnut: yep
<xdarklight> sgnut: (it's a multi-stage boot process though, so the bootloader binary contains more than "just" u-boot, see here for more info about the closed-source parts that are included: )
<sgnut> xdarklight: thank you very much for all the information :)
* sgnut time to sleep
<sgnut> xdarklight: thank you again :)
<sgnut> c u
sgnut has quit [Quit: leaving]