I added support for PDM9655 PMIC regulators and SPMI.
These will be needed later for scaling, UBI cores as well as SD/eMMC support.
Unfortunately, I will be having much less time in the following days so any help with the massive amounts of work needed for IPQ807x would be great.
I should have more time Friday and over the weekend.
Last time I checked mainline ath11k it had exactly the same issue. But it could scan and list local ssid
Not really sure how to debug that but I'll give if a go.
Thanks.
I mean it makes no sense to see the amount of work on ath11k and for it not have a working AP.
If they only had some docs.
I mean, even in the PR for ath11k they wrote that it support AP, mesh and station modes.
It's could always be this HW that's slightly odd but it should be supported.
Its a shame there isn't much more accessible ipq807X hardware around to validate on (better yet a development board)
I dont think that its odd, its basically AC01 reference board.
I have been trying to get a HK01 development board, but I cant get it at work and its way too expensive for me.
Heck, every other IPQ807x board is too expensive for me.
Ok, I tested and confirmed that we need the board.bin from the stock FW for the QCA9889 radio.
Otherwise, it advertises the 5G band which it cant do.
UPDATE: Misinformation from my side, it still advertises both bands even after I packaged the board.bin
So, this thing could be potentially usefull.
As far as I can tell the stock FW also advertises both bands for it.
I also gave the ath11k radios a go, and with the board file pulled from stock FW it will start a AP and broadcast it with NOHT htmode
Thanks for checking the ath11k radios with the stock board file, I have tested the same this morning. At lest ath11k seems to be working as expected.
I will have a look around for the eth / switch drivers, unsure if any work has happened upstream for that.
Will also have a look at the warning around gcc_usb1_master_clk (that has been on every non qcom kernel I have seen)
EDIT: odd to see VHT seems to be disabled / not detected, don't think this is a reg issue tho
From iw list
Supported Channel Width: neither 160 nor 80+80
VHT TX highest supported: 0 Mbps
Yeah, I think I said that it only works with NOHT as VHT is not advertised at all.
Even though it kind of works in non HT legacy channels its not correct as it constantly throws BSS survey errors.
So its either a bug in ath11k as ID-s it reads are really weird or some other combination of issues.
I would personally love to try this on 5.10 instead of 5.8 WLAN driver stack.
I think that those USB clocks cant be disabled from SW, I took a look at QCA driver and they have some kind of HW_MANAGED flags on that AHB master clock writing that RGCR is not SW controllable.
This flag does not exist upstream, I dont think that those warnings really matter as USB clocks being on really dont conflict with anything.
@robimarko sorry for OT... You said you are using usb to ttl serial with no selector for 1.8v. (I think we have the same adapter that have only 3.3 and 5v (pcb red)). Could you confirm that I can use it for the ax3600 without any additional device?
Yes, I am using a red FT232RL based clone with nothing else but voltage set to 3.3V using the jumper.
Anyway brought the router.. will join the party asap ahahha (estimated ship 16 nov)
Awesome, we really need some help as this is all test and trial.
Heck, we dont even have CPU scaling supported as that requires another set of regulator drivers and PLL clock driver(This one should be easy)
Should be easy (only dts entries). What i'm dubious is the scaling driver... Wonder if they still have the same problem with cache scaling (saw some patch to add a devfreq driver that can sync with the cpu freq but I think it got rejected.) (also tsens should work out of the box)
Also about ethernet driver. What are we using? DSA or still swconfig?
Its not only DTS entries, we are still missing the CPR APSS voltage regulator and APSS PLL clk driver.
I dont think they are scaling the cache at all, or its being done outside of Linux control as only the generic OPP DT frequency scaling is used.
Tsens does not work out of the box, they have modified the v2 a bit as it seems.
Their ethernet driver is using switchdev + the awfull SSDK for the PHY-s/switch.
I dont like that at all.
PHY-s are not hard as I already have a working QCA8075 PHY driver, QCA8081 for 2.5G is much simpler and it should not be hard and for 10G Aquantia ones are already mainline.
But the switch is still the same one from IPQ40xx with the same issues, but they now have multiple EDMA ethernet adapters modified to run at higher speeds.
MDIO controller is the same one as in IPQ40xx, I have upstreamed that and even Clause 45 support was merged into 5.10.
I will add clock handling to it as well as IPQ807x/IPQ60xx have a separate MDIO clocks.
No pending upstream patches for anything clk or networking related stuff.
Patch upstream pending for review (or they didn't even tried to push that?)
So it will be a task of take the code from qsdk and port to 5.10
For the start at least
FYI i am using this adapter, supports 1.8v / 2.5v / 3.3v / 5v logic (FTDI FT232RL based)
https://www.amazon.co.uk/DSD-TECH-SH-U09C5-Converter-Support/dp/B07WX2DSVB
So we are all basically using the FT232RL.
Also, I just pushed MDIO support as well.
Ordered now a FT232RL with 1.8V option right here:
It'll probably arrive within a few weeks. until then, if you need any checks with stock international firmware - please let me know.
