<warpme_>
plaes: is fifteenhex (or karabek) works for you on 5.13 mainline? In my case (tested only karabek) it causes kernel issues exactly like jernej's had with cw1200
<plaes>
warpme_: haven't tested this for a while...
<plaes>
you could try to get this pushed to staging..
<arnd>
plaes: adding it to staging sounds like a good idea. I also like your approach of making it more like cw1200 and eventually merging the two into one, but those two things don't have to be mutually exclusive, it's probably easier to do in staging than in a private tree
<arnd>
plaes: did you run into a show-stopper at some point with your attempt, or just lack of time to work on it?
<plaes>
I don't remember :(
<plaes>
judging by the dates, it seems to be the time I spent at mother of law's house and there was not much else to do.. :P
<plaes>
but yeah, I don't really know how to push this kind of big chunk to kernel.. (I once asked Greg KH about this, but never received a reply)
<arnd>
plaes: gregkh usually replies to patches and pull requests. If it's really big, I would suggest a pull request that adds it to staging, ideally with some retrofitted git history, and Cc enough people that can give their Ack for the merge
<arnd>
in addition to the driver, there needs to be a TODO file with an outline of what you expect that needs to be fixed to graduate the driver out of staging, in this case integrating it into cw1200.
<warpme_>
ah ok. keeping in mind amount of cheap tvboxes with this chip - i agree it is worth to add it to mainline (even keeping in mind it is only 65mbps chip so use-case is probably mainly iot-like?). isn't good idea to sync frontend part with bsp (https://github.com/orangepi-xunlong/linux-orangepi/tree/06f40bef0d9a08c233b4b2ed6f9064c3abe3ecb6/drivers/net/wireless/xr819)
<arnd>
and there should be a good desciption of the state of the driver, what others have attempted in the past etc
<gamiee>
warpme_ : what? XR819 is only 65mbps chip ????
<warpme_>
iirc datascheet shows it offers only ofdm mcs variants up-to 65Mbps (air interface value). User throughput is usually 50-60% of air (radio) throughput (forward error correction + media access protocol overheads are significant iirc)
<arnd>
warpme_: it doesn't matter at all how fast or how common the chip is, what matters is whether someone is willing to work on it upstream
<arnd>
and it seems that there are enough people that have the hardware and are capable of working on it
<warpme_>
sure. thats obvious :-) but motivation also depends on how "attractive", wide-spread (=demand) & prospective target is. isn't?
<apritzel>
it could become "attractive" when it's the only way to connect to some network ...
<apritzel>
(regardless of reliability and speed)
<warpme_>
for sure. that's why i thing it is really worth to mainline it - even when it is only 65Mbps wifi silicon :-)
<arnd>
what is the relation between xr819, xr819, uwe5622 and aw958a? Are these two unrelated product lines with two chips each, or are they all in the same family?
<apritzel>
AW958a is the name of the chip used in newer boards, and uwe5622 seems to be used for the driver name in the BSP for that
<apritzel>
AFAIK xr819 is unrelated?
<plaes>
yeah, to be 100% sure, decaps of xr819 and other chips are needed..
<warpme_>
aw5622 (a.k.a aw859a) and xr819 are day & night different. aw895 is upto 802.1ac dual-band while xr819 is only 802.1n (and only SISO)
<arnd>
in the linux-orangepi tree, xr819 and xr829 have very similar drivers that both look like cw1200. Just based on the numbers I would guess that xr819 might be a cw1100 variant, while xr829 would be a cw1200
<arnd>
I have discussed upstreaming their wireless drivers with spreadtrum/unisoc developers in the past, but nothing has ever come of this, presumably because the way it is written was just too different from what linux drivers look like otherwise
<arnd>
not sure if aw859a/aw5622/uwe5622 is related to the driver we discussed back then, or if this is a different unisoc produc
<arnd>
the developers I worked with were from Spreadtrum, but it's possible they used RDA wifi even before the merger
<warpme_>
iirc allwinner in-sourcing history was totally different: iirc xr819 comes to aw as ericsson IP cheap sell. E/// was selling it to anybody interested (as E/// decided to stop developent of wifi business and was interested for maximizing devel spendings recovery by selling IP to any interested). uwe5622 is spreadtrum desing acquired by unisoc company which actively wants to sell as OEM to vendors like aw (i might be wrong as
<warpme_>
this is from my rusty memory)
<plaes>
does anyone know about "Redpine Signals Inc" :)
<arnd>
warpme_: spreadtrum was renamed to unisoc after the merger with RDA
<warpme_>
in this context uwe5622 is really promissing imho. bsp already shows code for: aml, hisil, aw & rk
<plaes>
nevermind rsi is actually in upstream kernel
<warpme_>
ah ok - it was merger - not acquisition :-)
<arnd>
I think technically it was a reorg within Tsinghua Unigroup that had acquired both RDA and Spreadtrum
<warpme_>
arnd: re: "not sure if aw859a/aw5622/uwe5622 is related to the driver we discussed back then, or if this is a different unisoc produc" - isn't that uwe5622 is based on old spreadtrum desing while uniscowcn (sc23xx) is new chip designed after rda & spread acquisition? In bsp it is in unisocwcn dir and seems to be much "better" aligned with mainline wifi infra? It looks like unisocwcn can also cover uwe5622?
<arnd>
apparently they submitted it last year but did not get it merged yet
<arnd>
this is marlin3/sc2355.c
<arnd>
again, not sure if this is related to any of the others
<warpme_>
do you know what sbc/tvboxes are using sc2355 ?
<arnd>
fairly sure this was for phones and tablets
<warpme_>
ah ok. so from "low-end market" perspective (guys like me wanting run mainline on most popular sbs/tvboxes) xr819 will be 1st wanted to see boy in town. aw5622 might be prospective (as bsp shows aml/aw/rk/hi) - but so far only i saw only 1 sbc with it.
<arnd>
if the marlin3/uwe5622/unisocwcn support becomes more interesting in the future, I could ask my contacts in unisoc about it
<warpme_>
indeed: usually the same code-name is guarantee high similarity in code....
<arnd>
so regarding the xr819 driver, someone would need to make an informed decision about which driver(s) to send first, given that there are at least half a dozen different out of tree copies of it by now
<arnd>
at least it's not as bad as the realtek drivers, which now have three separate implementations, with the one from the vendor having one copy for each of the 30 chip variants
<warpme_>
when you will contact them - maybe it is worth also to ask about plans for: 1\ do they have plan to go with convergent umbrella driver for multiple chips (like i.e. relatek); 2\ if 1\ is yes - then what is list (i.e. ubrealla driver for uve5622 & sc23xx)
gediz0x539 has quit [Quit: Leaving]
<warpme_>
arnd: indeed rtl is book-case of spaghetti effect in bad programming.....
faruk has quit []
<apritzel>
not sure how far Jernej came or will come (or has time to follow up on this), but other than that plaes' version is probably the most promising code-wise
<apritzel>
since it has a clear non-staging perspective
<apritzel>
we could then check the fixes in the other drivers and port them over to the staging/proper mainline tree
<apritzel>
I think the other drivers are all BSP based (read: horribly misaligned with mainline) and realistically would be doomed to be in staging forever - which might actually even prevent their initial merge in there
libv_ has joined #linux-sunxi
gediz0x539 has joined #linux-sunxi
libv has quit [Ping timeout: 480 seconds]
<arnd>
apritzel: on the other hand, it looks like the fifteenhex version may be the one that works best since it is what gets shipped in armbian.
libv_ is now known as libv
<arnd>
it also seems that this started from the exact same codebase as plaes version, so it may be possible to rebase plaes' patches on top of fifteenhex's version
<arnd>
(the reverse would be much harder because of the number and type of changes between the two)
<apritzel>
arnd: yeah, *somehow* take the changes from fifteenhex and put them on top (or below) plaes' version
<arnd>
it has to be below
<arnd>
plaes changes are mostly mechanical but completely break a rebase on top, fifteenhex has 144 commits that are mostly bugfixes and rebases to work with later kernels
<plaes>
yeah, I have too many "stupid" changes
<apritzel>
fair enough, I didn't look in detail, just wanted to point out that sending fifteenhex' version directly (even though it's the best working) is not very future proof
montjoie_ is now known as montjoie
<apritzel>
plaes: you did exactly right, because it easily allows to apply your changes to a slightly different code base
<apritzel>
(what arnd pointed out)
prefixcactus has quit [Read error: No route to host]
Mangy_Dog has joined #linux-sunxi
choozy has joined #linux-sunxi
<gediz0x539>
wiki is down. i get a cloudflare error 522 page. fyi :)
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #linux-sunxi
gsz has joined #linux-sunxi
choozy has quit [Remote host closed the connection]
gediz0x539 has quit [Quit: Leaving]
choozy has joined #linux-sunxi
tnovotny has joined #linux-sunxi
choozy has quit [Remote host closed the connection]
ftg has joined #linux-sunxi
tnovotny has quit []
<jernej>
arnd: afaik xr819 and xr829 difference is bluetooth
<jernej>
but I don't have any device with xr829
<jernej>
arnd: cw1200 driver reports cw1x60 type for xr819
<libv>
seems like it repaired itself...
vagrantc has joined #linux-sunxi
choozy has joined #linux-sunxi
choozy has quit [Ping timeout: 480 seconds]
<jernej>
ok, so cw1200 loads xr819 bootloader & FW, registers interface, but "ifconfig wlan0 up" crashes FW
<jernej>
progress, but still not enough :)
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
<hexdump0815>
warpme_: regarding you cpufreq and clocking experiments - did you already try how far you can get with the bsp kernel?
<hexdump0815>
warpme_: it might help to sort out if its a hardware limitation of your box or a software issue
<hexdump0815>
warpme_: i was able to get a h616 tv box running stable at up to 1.8ghz and a h313 one up to 1.5ghz or 1.7ghz with slightly increased voltage using the bsp kernel
<insep>
is it possible to get access to nand on cubieboard with mainline linux?
<apritzel>
hexdump0815: but what role should the BSP kernel play in here? Shouldn't it be sufficient to just use a fixed OPP with a higher voltage (no actual DVFS)?
<hexdump0815>
apritzel: iirc warpme had problems with opps above 1.2ghz on the box and it was not clear if it was due to some hw layout or maybe to to some register setting missing
<hexdump0815>
apritzel: just checking if the same problems exist with the bsp kernel could maybe rule out hw limits, as if 1.5ghz works there the hw would be capable of that
<apritzel>
hexdump0815: are the OPPs in your dtb from the BSP? Or did you trial and error them?
<hexdump0815>
apritzel: they are from bsp as far as they they were in there (i think up to 1.5ghz) - everything above was trial and error, a bit based on h6 and some extrapolation i think
<hexdump0815>
apritzel: i was really surprised that i was able to drive it up to 1.8ghz and iirc the h616 was still close to not throttling without any extra cooling - the h313 did not get that high and was running way hotter than the h616
<warpme_>
hexdump0815: thx for hint. in my dt i'm using opp defs from bsp and can't go above 1.3G. as you can go higher - it looks like issue isn't dt opp but probably vcpu or pll related in mainline code. unfortunately opi-zero2 seems not to have tp pads with vdd_cpu so i need to look carefully where to measure vdd_vpu with multimeter. let me look on this tomorrow.
<warpme_>
to test i'll also try to decrease 1.3G opp voltage to unreasonable low value. if 1.3G opp will stop working - then pmic vdd_cpu i'll qualify as "controlled" ok - and pll hypothesis will be highest one....
<apritzel>
I configured U-Boot to setup 1.5GHz@1.12V, and hackbench seemed happy
<warpme_>
apritzel: and can you replicate the same in kernel?
<apritzel>
this is in the kernel, I just left Linux clueless about voltage and frequency
<apritzel>
(so it doesn't touch them)
<apritzel>
I doubt that the PLL is an issue, but I will have a look
<apritzel>
warpme_: did you see this of_device_is_compatible() call in sun50i-cpufreq-nvmem.c?
hlauer has quit [Ping timeout: 480 seconds]
cmeerw has quit [Ping timeout: 480 seconds]
choozy has quit [Remote host closed the connection]
Daanct12 has quit [Ping timeout: 480 seconds]
<apritzel>
warpme_: frequency and voltage work(TM) on my OPi-Zero2, with just some operating-points table in there (cpufreq-dt, not nvmem), up to 1.8Ghz@1.12V