<konradybcio>
the sec/ns split seems to not matter very much here
<aka_[m]>
they are 32CB
<konradybcio>
this write prooobably just enables all sec irqs
<aka_[m]>
"to only 1 line at gic" so every CB just will throw single interrupt?
<aka_[m]>
so you get like 3 CBs using same interrupt
<aka_[m]>
konradybcio: in ds you posted before it writes to localbase it seems to do __program_iommu_secure
<konradybcio>
aka_ yes that's fine.. tlmm also has a single interrupt but then there's registers allowing you to tell which pin changed
<minecrell>
aka_[m]: you should be able to ignore SMMU_INTR_SEL_* on any platform != msm8916 since qcom introduced the funny "interrupt aggregation logic" only for 8916 and dropped it again immediately after
<minecrell>
but I didn't really get what you are trying to do
<aka_[m]>
minecrell: Konrad wants me to provide reg on iommu node and from what I see it's only used to toggle that funny register
<minecrell>
I guess if qcom_iommu does support it, the platform does have the register and downstream writes it as well there is no harm to just add it
<minecrell>
but I'm 95% sure it will change absolutely nothing
<aka_[m]>
It doesn't i guess
<minecrell>
that's probably just an historical artifact in the hw
<aka_[m]>
Ds have 2 regs in iommu base
<aka_[m]>
On 8916
<aka_[m]>
Smmu-v2. Dtsi
<aka_[m]>
Single reg on 8976/8953
<aka_[m]>
Second reg on 8916 specify that smmu_ss_local base containing This rrg
<aka_[m]>
Dumb swiftkey
<minecrell>
In this case I'd just use whatever works easiest for making bindings and driver happy. If you get warnings when omitting the reg then you might as well specify it and do the redundant write, if there are no warnings you might as well omit it
<aka_[m]>
konradybcio: regarding gpu opp table if I haven't said yet freqs bit differ because when porting gcc you have skipped adding gpll3 derived frequencies into gfx3d
<aka_[m]>
minecrell: reg is optional
<minecrell>
I'm spontaneously not sure how the unit address (iommu@1ef0000) works with just "ranges" but no "reg", so that may be an argument in favor of reg
<minecrell>
or do you use the ranges address then?
<konradybcio>
yeah i was curious about lack of this warning as well
<aka_[m]>
Ain't ranges used my DMA or something?
<konradybcio>
ranges are used for child reg calculation
<konradybcio>
and for mapping the parent mmio space
<aka_[m]>
On 8953 seems it got without reg
<aka_[m]>
So guess I'm doing with proper reg if it ain't breaking anything
<aka_[m]>
But need testing and latest next probably is bit broken
<aka_[m]>
konradybcio: still ain't reg outside of ranges?
<aka_[m]>
Like ctxs are before ss_local
<konradybcio>
i mean, there may be more than one reg entry
<aka_[m]>
<konradybcio> "i mean, there may be more than..." <- can you check rest of those: