deathmist has quit [Remote host closed the connection]
deathmist has joined #linux-msm
mgonzalez-2 has joined #linux-msm
<mgonzalez-2>
Ahoy
deathmist has quit [Remote host closed the connection]
deathmist has joined #linux-msm
<mgonzalez-2>
krzk: it is not clear to me what "msm8998 SoC does not have WiFi" means.
<mgonzalez-2>
Are you just saying that the wlan IP block is not etched in the msm8998 SoC?
<krzk>
mgonzalez-2: yes, that was my statement.
<mgonzalez-2>
I worked on a SoC a few years back, which integrated a PCIe root complex from DesignWare.
<krzk>
wlan is wcn, separate piece, although how separate that's another question
<mgonzalez-2>
Rob explained that I should define a SoC-specific compatible string for the RC, in case we had SoC-specific glitches.
<mgonzalez-2>
Ah I see, like it's in another part of the board, not in the SoC?
<krzk>
writing bindings tell that
<krzk>
but here, is thi spart of SoC or not?
<mgonzalez-2>
That is a good question. I think Jeff is the best person to answer that question!
<mgonzalez-2>
It was Conor who suggested we should have a SoC-specific binding, IIRC
<mgonzalez-2>
I don't really have a preferred solution, as long as a solution is accepted :)
<krzk>
mgonzalez-2: neither Conor nor Rob, nor actually me, know exactly that hardware
<krzk>
writing bindings gives you the guideline, but it does not say that non-soc parts should have soc component.
<krzk>
It only says about specific compatibles.
<mgonzalez-2>
Even if a board has 2 completely separate chips, the way they are connected together might be specific
<krzk>
mgonzalez-2: which does not make TI LM75 temperature sensor part of a SoC!
<krzk>
This is some weird twist of meaning of bindings.
<mgonzalez-2>
I suppose you have more experience than I with these things, I defer to you.
<mgonzalez-2>
It's a bit frustrating that this 3 year-old bug is only now slowly being investigated
<mgonzalez-2>
I mean, the PostMarketOS guys already documented all these issues
<mgonzalez-2>
I guess they were never brought to the attention of the ath10k guys
<jhugo>
krzk mgonzalez-2 according to the block diagram, the Adrastea WLAN is integrated into the SoC
<jhugo>
For 8998
<mgonzalez-2>
jhugo: hello you're up early :)
<mgonzalez-2>
Adrastea = ath10k ?
<jhugo>
mgonzalez-2 9am is early? :)
<mgonzalez-2>
Oh I thought you were on the west coast :)
<mgonzalez-2>
jhugo: it was bamse who reverse-engineered (or rewrote) most of the user-space tools?
<jhugo>
mgonzalez-2 yes
<mgonzalez-2>
Haven't read from him here in since I got back
<mgonzalez-2>
It feels like the user-space architecture is even more hairy than the kernel driver :(
<jhugo>
from what I can find, adrastea is the ath10k block
<jhugo>
integrated with the SoC
<jhugo>
8998 appears to have the 1.0 version of the block
<mgonzalez-2>
lumag: krzk: if the ath10k in integrated with the SoC, then there could be SoC-specific integration glitches, and a SoC-specific compatible string makes sense.
<mgonzalez-2>
*is integrated
<krzk>
mgonzalez-2: yes, again, please explain briefly this in commit msg adding soc-specific compatible
<mgonzalez-2>
krzk: I understand. But this is just a small part of the picture.
<mgonzalez-2>
It's still unclear how lumag & Jeff want the issue worked around.
<mgonzalez-2>
I will document how the code we use works, and wait for Jeff's and Kalle's guidance.
<lumag>
mgonzalez-2, but it is not. wcn3990 is a separate chip
<lumag>
It is not a part of msm8998
<mgonzalez-2>
lumag: jhugo has access to qcom data sheets
<mgonzalez-2>
He helped me mainline PCIe & SMMU & UFS
<mgonzalez-2>
I also had a working driver for the TSPP interface, but the media devs have really looooow BW for review, so it was never merged
<mgonzalez-2>
And qcom refused to provide documentation to the TSPP's DMA engine
<lumag>
mgonzalez-2, TSPP?
<lumag>
mgonzalez-2, wcn3990 is a separate chip. It is integrated with msm8998 from the platform POV, but it is still a separate chip.
<mgonzalez-2>
Transport Stream Packet errr Pinterface?
<lumag>
But we need to descrbie the integration of that chip with the platform.
<mgonzalez-2>
we used a phone SoC for a TV set-top box :)
<lumag>
That's why we have the 8-bit quirk property in the DT
<lumag>
mgonzalez-2, I know. I even have a device thanks to rawoul. I started hacking the display part up last year, but then I didn't have time anymore.
<lumag>
mgonzalez-2, I'll test this later, just to check that it doesn't break things. But I think that the patch hits the list should actually move the code.
<mgonzalez-2>
Moves what code?
<mgonzalez-2>
lumag: the patch moves the ath10k_qmi_event_msa_ready() statement.
<mgonzalez-2>
(sorry for stating the obvious :)
<lumag>
from ath10k_qmi_event_msa_ready() to ath10k_qmi_event_server_arrive()
<lumag>
And maybe drop the event completely
<lumag>
But let's confirm that it works first
<mgonzalez-2>
Not so chirurgical, the change becomes then :)
<mgonzalez-2>
Function is static and used only once, compiler will inline it by itself
<lumag>
mgonzalez-2, yes. But it means that there is an MSA READY even that we are handling
<lumag>
upstream patches tend to be less hackish
<lumag>
btw, tested sm8150, works.
<mgonzalez-2>
If the event does arrive, it seems smart to log it
<mgonzalez-2>
And doing it in the work queue sounds safer than in the indicator handler
<lumag>
The event, yes.
<mgonzalez-2>
So you get the indicator, but ignoring it works anyway?
<lumag>
mgonzalez-2, yes. But ath10k_qmi_event_msa_ready() doesn't make sense anymore.
<lumag>
Yes.
<lumag>
It makes no difference, where do we log the event. Neither place is more dangerous
<mgonzalez-2>
I thought the ind handler might be an ISR?
flto_ has joined #linux-msm
cbraga3 has joined #linux-msm
<mgonzalez-2>
Hello link-time optimization :)
qyousef_ has joined #linux-msm
SanchayanMaity__ has joined #linux-msm
pundir_ has joined #linux-msm
linusw_ has joined #linux-msm
flto has quit [resistance.oftc.net larich.oftc.net]
cbraga has quit [resistance.oftc.net larich.oftc.net]
linusw has quit [resistance.oftc.net larich.oftc.net]
qyousef has quit [resistance.oftc.net larich.oftc.net]
SanchayanMaity_ has quit [resistance.oftc.net larich.oftc.net]
pundir has quit [resistance.oftc.net larich.oftc.net]
qyousef_ is now known as qyousef
<lumag>
mgonzalez-2, printk is irq-safe
pundir_ is now known as pundir
<mgonzalez-2>
To be IRQ safe, it must mask IRQs?
<lumag>
IRQs are masked during IRQ handling
<mgonzalez-2>
It's best to minimize time spent in ISR... :/
<lumag>
mgonzalez-2, tested, works on sdm845 and qrb2210. I'll handle sda660 and qrb4210 later
<aka_[m]>
I have asked about that long time ago and forgot answers so I'm going to ask again.
<aka_[m]>
Do anyone here own qcs404 board?
<aka_[m]>
Qcs403, 405 whatever from this family
mgonzalez-2 has quit [Quit: Page closed]
<lumag>
aka_[m], vkoul, should have the EVB.
<lumag>
I have customer devices with qcs404
jhovold has quit [Ping timeout: 480 seconds]
<bamse>
aka_[m]: yes, i do...
pespin_ has quit []
<lumag>
mgonzalez, tested qrb4210
<aka_[m]>
lumag: bamse I'm fine with any tbh, it's about icc
<aka_[m]>
I have a patch for adding more nodes, and other stuff
<aka_[m]>
But icc is annoying with nodes where sometimes slave or master do -6
<konradybcio>
aka_: on 8974 99% of the nodes do it 😬
<konradybcio>
have you checked if downstream does the same but ignores it?
<konradybcio>
that's been on my bucket list for.. ...ever
<aka_[m]>
konradybcio: most nodes doing -6 appears to be outside of our access
<aka_[m]>
like some debug subsystems
<aka_[m]>
dehr/q6lpass
<aka_[m]>
wcss
<konradybcio>
i wouldn't be surprised if the scripts that generated the topology went unaware of ownership then
<lumag>
mgonzalez, on sda660 WiFi timeouts and crashes the firmware without your patch. With your patch it hangs the board. But there can be possible issues with smmu, it was particularly nasty on that board.
<aka_[m]>
konradybcio: have you tested wifi on Lenovo?
<aka_[m]>
I just added wifi node but no opportunity to try on redmi 9t