<vkoul>
flto: the spmi patch is wip, I will fix that and post v2 next week after merge window closes
<vkoul>
let me check on apps_smmu and usb ...
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
flowriser has quit [Ping timeout: 480 seconds]
flowriser has joined #linux-msm
pevik_ has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
frytaped has joined #linux-msm
frytaped has quit [Quit: frytaped]
Daanct12 has joined #linux-msm
Danct12 has quit [Ping timeout: 480 seconds]
pevik_ has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
<z3ntu>
bamse: hmmm the pmic being on a different address also affects the interrupts, e.g. `interrupts = <0x0 0x62 0x1 IRQ_TYPE_EDGE_RISING>` needs to become `<0x6 0x62 0x1 IRQ_TYPE_EDGE_RISING>`
<Mis012[m]>
well... I guess that can be overwritten if we find a way to reuse the `dtsi`s, but what should the default be :D
<Marijn[m]>
z3ntu: And "what if" you use some macro defines for that? `#define PMIC_IDX 0x6 #include <pmic.dtsi>`?
<Mis012[m]>
and of course `s/pmk8350_vadc/pmk8350_at_##__SID__##_vadc/`
<Mis012[m]>
I don't see any issue with this approach at all 🧱 👀
<z3ntu>
Without changing some fundamentals I don't see a way around giant macros .. :/ interrupts could be changed in the driver to use the sid as first parameter instead, node+reg can be by moving it into the consumer but labels also kind of only work by creating them with macros
<Mis012[m]>
z3ntu: I think my macro is less ugly than hacks in the driver...
<Mis012[m]>
so at some point not using macros doesn't make sense if the reason is that macros are ugly
<Mis012[m]>
and I have seen more ugly macros than this one fwiw
<Marijn[m]>
Perhaps you can make the macro less ugly by just defining parameters like `__SID__` and then `#include`'ing that chunk? Saves you from having all these incessant backslashes
<Mis012[m]>
not sure what it's trying to say, maybe try to get edl.py to work
<bamse>
z3ntu: yes, but that part i just consider ugly...think we should have the qcom,spmi-pmic driver build a irq hierarchy ontop of the lower layers to hide that fact
<Mis012[m]>
bamse: hm, you mean make an interrupt controller?
<Mis012[m]>
I can see how the first thing here not being a phandle to an interrupt controller is a bit weird
pevik_ has quit [Ping timeout: 480 seconds]
<bamse>
Mis012[m]: the of_irq_get() code walks up the parent's chain and finds the #interrupt-cells and uses that
<bamse>
Mis012[m]: or if it finds a interrupt-parent property it uses that
<bamse>
Mis012[m]: so the typical scenario is that we walk up the tree and find a interrupt-parent property pointing to &intc in the root node and use that
<Mis012[m]>
bamse: then that's standard behavior?
<bamse>
Mis012[m]: yeah it is, it's just that we find the spmi-pmic being an interrupt controller in the case of the pmic...so that's the controller we get
<Mis012[m]>
bamse: well... I assume there is no pointless muxing, so presumably using any other interrupt controller would mean you don't get the interrupts? :P
<bamse>
Mis012[m]: right, the pmic interrupt controller is a different source of interrupts than the gic
<bamse>
Mis012[m]: that said, there's one gic interrupt that signals the pmic-driver that there's an interrupt in the pmic interrupt-controller
<bamse>
Mis012[m]: so it knows when to go look at the pmic interrupt registers to figure out which pmic-interrupt fired
<Mis012[m]>
that sounds like sane interrupt chaining
<bamse>
right
<bamse>
and what i suggested above was that we can remove the USID requirement by creating an irq_domain that maps some range of interrupts onto the parent range, but prefixed with the USID of the individual pmic
<Mis012[m]>
that's a fully devicetree-side construct, right?
<bamse>
nah, you need some plumbing code to set up the mapping
<bamse>
and you need to extract the USID from the pmic's reg property and tack that onto the irq description during resolution
<Mis012[m]>
hm...
<Mis012[m]>
sounds a bit magic
<bamse>
yeah, it is, and it's quite nice
<Mis012[m]>
I don't usually use magic as a compliment :P
<bamse>
we use that for things such as the pmic gpios, where each gpio can be used as interrupt source, but each gpio has a dedicated interrupt in the pmic's interrupt-controller space
<Mis012[m]>
hm, I see
<bamse>
so that way you can treat the gpio-controller as a set of interrupts, where interrupt 1 would relate to gpio 1...but as you request it you actually get say pmic interrupt 192
<Mis012[m]>
yeah... that convention would be a pity to loose
<Mis012[m]>
bamse: speaking of magic, I guess you won't tell me what the bits inside SSCAON_CONFIG1/2 do?
<Mis012[m]>
since the FLAT documents the whole 32 bits as one field
<Mis012[m]>
but the hypervisor accesses those fields in a manner where it's clear that it's setting/clearing individual bits
<bamse>
have you looked at drivers/remoteproc/qcom_q6v5_wcss.c ?
<bamse>
it seems to define a few of the bits at least and i would not be surprised if that's the same layout as you sscaon register
<Mis012[m]>
bamse: well, it doesn't define any of the bits that I need
<Mis012[m]>
bamse: also, it writes to RMB, which means that there is probably something listening on the other end of that, doing the actual writes
<Mis012[m]>
but idk what that would be, certainly not anything that I have sources for
<bamse>
most likely yes, RMB seems to be some sort of protocol...might be a hardware state machine though...
<Mis012[m]>
it's called Remote Message Buffer
<bamse>
i don't think i have found the documentation for the rmb messages
<Mis012[m]>
on msm8998, it seems to be used by modem fw to get info from SBL on whether something has finished
<Mis012[m]>
bamse: but on msm8998, there are actual SSCAON_CONFIG1/2 registers
<Mis012[m]>
bamse: actually, one other suspect thing is that these registers don't seem to exist on msm8976, so whatever is going on is more complicated than a proxy
<Mis012[m]>
I don't recall why I checked 8976 specifically, I guess it was mention in the driver?
<Mis012[m]>
*mentioned
<aka_[m]>
Mis012: or maybe you have flashbacks from chat with me xd
<Mis012[m]>
bamse: what would generally be the reason for the bitfields to not be described in the FLAT?
<aka_[m]>
8976 does nett have dedicated ssc core and uses adsp for that like other ones
<Mis012[m]>
well...
<Mis012[m]>
idk
<aka_[m]>
Mis012[m]: Blame qcom obv
<aka_[m]>
Not like you supposed to look into them in first place
<Mis012[m]>
I guess it's possible that the RMBs are used as an abstraction for that reason?
<Mis012[m]>
aka_: since the FLAT is an artifact of the process of parsing the HDL, I think it's fair to say there would be some particular reason
<Mis012[m]>
aka_[m]: debatable
<Mis012[m]>
they seem to be used to generate header files for firmwares
<Mis012[m]>
and that's pretty close to how I'm using them :P