<z3ntu>
bamse: Pretty sure I did that mistake; anyways with your new version it compiles fine but I still don't see anything on the led... `multi_intensity` being `255 255 255` and then `echo 255 > brightness` does nothing. Did you maybe change some logic underneath so my dt bindings have to be changed? They worked with the last revision, I have reg=7, 6 & 5 for red, green & blue
<z3ntu>
bamse: If not, I'll look at the register values next what changed since the last revision
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
djakov has quit [Remote host closed the connection]
djakov has joined #linux-msm
<bamse>
z3ntu: i didn't test this latest version on a rgb device, will see if i can get that done as well...
<minecrell>
bamse: I know it's quite late but any chance we can get https://lore.kernel.org/linux-arm-msm/20210618111556.53416-1-stephan@gerhold.net/ still into 5.14? (Perhaps through the rproc tree where it "fixes" things?). I use the devm_ variant in my bam-dmux driver so that would avoid having to coordinate with the net people later
<bamse>
minecrell: no sorry, i'm still hoping that they will pick up my pull request from earlier this week...
<bamse>
minecrell: but if you're ready to send the bam-dmux after the merge window you could include this patch in the series and i'll ack it for the netdev guys to take it through their tree
<minecrell>
ugh, that series will already be big enough as-is :/
<minecrell>
I guess I'll rather let it leak like qcom_q6v5 has been forever then :D
<minecrell>
and fix it later
<minecrell>
bamse: but iirc you send the remoteproc stuff directly to Linus during the merge window? Not sure where you'd have normally applied it since the series includes two remoteproc patches
<bamse>
minecrell: but this is drivers/soc/qcom, so it should go through the qcom treee...which is sent throught soc@
<minecrell>
bamse: well patch 2/3 and 3/3 are drivers/remoteproc :D
<minecrell>
but it's fine I guess, I'll find some way :)
<bamse>
ahhhh, didn't see those
<bamse>
now i see what you're saying
<bamse>
the remoteproc-me can certainly pick up patches for a few more days :)
<minecrell>
Ah, perfect thanks :D And sorry for the confusion
<minecrell>
bamse: Huh, is your Reviewed-by: like an ack from yourself for the qcom tree? :D
ServerStatsDiscoverertraveler4 has joined #linux-msm
cmeerw has joined #linux-msm
MatrixTravelerbot[m] has joined #linux-msm
<bamse>
minecrell: it's just saying that i did review it...just didn't bother with the two other patches
<bamse>
minecrell: it's in the CI-tumbler now, hopefully it will come out in good shape :)
<konradybcio>
bamse is 8994 supposed to prevent me from reading ANY PCIe debug register (that includes things like revision)? :|
<minecrell>
bamse: Ah, you usually don't do that when you are the one applying the patch so I was confused
<konradybcio>
I'm constantly getting a 96000010 mmu serror
<konradybcio>
even downstream, with "proper" iommus
<Mis012[m]>
konradybcio: maybe you can read the smmu configuration and find out? :D
<konradybcio>
on sony? :)
<Mis012[m]>
well, it doesn't have to be read protected
<Mis012[m]>
write protecting should be enough
<Mis012[m]>
and since Linux actually has drivers for smmus...
<konradybcio>
except it's 8974 *mmu
<Mis012[m]>
8974 doesn't use smmus?
<Mis012[m]>
and doesn't have PCI-E
<konradybcio>
8994 uses half of 8974's IP
<konradybcio>
that includes the iommus
<Mis012[m]>
interesting
<minecrell>
Well, the 8974 IOMMU is like 8916 IOMMU (just with extra peculiarities for configuration apparently)
<minecrell>
and the 8916 IOMMU reportely is a SMMU
<minecrell>
"An iommu driver for Qualcomm "B" family devices which do implement the ARM SMMU spec, but not in a way that is compatible with how the arm-smmu driver is designed."
<minecrell>
kind of typical for qcom :P
<Mis012[m]>
>not in a way that is compatible with how the arm-smmu driver is designed
<Mis012[m]>
are they implying that it technically doesn't violate the spec?
<Mis012[m]>
that would be pretty qcom of them indeed
<Mis012[m]>
see also: ELF files
<minecrell>
Mis012[m]: The SMMU is configured from TZ, my guess is that they just lock it
<minecrell>
According to the APQ8016E TRM it's a standard ARM® CoreLink MMU-500 System Memory Management Unit (SMMU)
<Mis012[m]>
so the extra driver is only needed because accessing random parts of the SMMU will crash your device? 👏 👏 👏
<minecrell>
So in other words, if you bring sanity to TZ you could probably use it with the standard Linux smmu driver
<minecrell>
yes, I'd say so
<konradybcio>
qcom breaks the spec on purpose
<konradybcio>
either because they can't design their hw or they can't write their sw
<konradybcio>
case and point: 8996 and later
<Mis012[m]>
not sure about msm8916, but I'm afraid that bringing sanity would jeopardize the security model :D
<minecrell>
I think fw is the magic broken word
<Mis012[m]>
yeah... the hw is usually pretty nice
<minecrell>
oh I forgot the TM after CoreLink
<Mis012[m]>
minecrell: isn't that SMMU used to prevent arm core from accessing stuff by chance :P
<minecrell>
I thought that's XPU
<Mis012[m]>
well, sadly they seem to be transitioning towards using SMMUs for that...
<Mis012[m]>
as per that surprisingly public doc
<Mis012[m]>
and msm8998 seems to be somewhat hybrid in using both approaches
<minecrell>
I don't think it makes sense to put a SMMU in front of ARM cores, there is the normal MMU for that
<konradybcio>
smmu separates the AP from peripherals
<minecrell>
but I guess you might configure it from something secure so that Linux can't abuse the SMMU to write into top secret stuff
<minecrell>
the hypervisor certainly can
<Mis012[m]>
I don't think it makes sense to not use XPUs for everything...
<Mis012[m]>
but I digress :(
<Mis012[m]>
`SMMU_500_REG_WRAPPER BASE 0x01E00000 SIZE=0x00110000 smmu_500_reg_wrapperaddr 31:0`
<minecrell>
Another strange thing is that qcom only uses the IOMMU for GPU/VENUS/CAMSS on 8916 and other older SoCs
<Mis012[m]>
that think is huge...
<Mis012[m]>
* that thing is huge...
<minecrell>
even though it also seems to sit in front of eMMC, Audio, BLSP and more
<Mis012[m]>
well, it should sit in front of the arm cores? :D
<Mis012[m]>
that's how that works
<bamse>
minecrell: right, when i apply patches i read them to see that they are good, but i often don't review them enough to write in the eternal git history that the i state the patch to be good shit<tm>
<bamse>
minecrell: so when i actually review things, i show that with the r-b
<minecrell>
bamse: Ah I see, thanks for clarifying :)
<konradybcio>
minecrell perhaps they didn't want to make it too complex for cheap socs
<Mis012[m]>
that's the appeal of msm8916
<konradybcio>
true that
<minecrell>
Well, thing is the firmware sets up those IOMMUs
<Mis012[m]>
not overcomplicated at all
<minecrell>
I tested them, they work :P
<bamse>
konradybcio: sounds good, but i presume you're referring to registers in the controller? those are not accessed through the iommu
<Mis012[m]>
minecrell: as in they work in Linux with standard driver?
<bamse>
konradybcio: so as long as things are clocked properly the SError should be a security violation
<konradybcio>
well, I'm wondering if it's a sony thing
<konradybcio>
but I don't have access to the 8992 xiaomi for now
<minecrell>
Mis012[m]: I just added some magic in the device tree and it seems to set up the SMMU, then writes virtual addresses into USB/Audio/SDHCI
<minecrell>
couldn't get the BLSP one working though#
<bamse>
konradybcio: i don't think they customize that...but i don't know
<konradybcio>
I know that sony employs almost the biggest security level from all OEMs
<konradybcio>
only microsoft was stricter
<konradybcio>
and maybe samsung in certain models
<konradybcio>
unless I don't know something :P
<Mis012[m]>
minecrell: I guess you can't unlock the registers without messing with TZ source?
<Mis012[m]>
to try the vanilla driver
<bamse>
konradybcio: it's been a long time since i poked around at sony
<konradybcio>
good for your sanity :D
<minecrell>
Mis012[m]: I would assume they lock them with XPU
<Mis012[m]>
well, probably
<bamse>
konradybcio: it's even longer since i worked on things there that was bad for my sanity ;)
<minecrell>
Mis012[m]: the contexts I listed there are definitely set up in TZ
<bamse>
konradybcio: last couple of years i pretty much only worked on open devices and upstream kernel stuff
<bamse>
konradybcio: and we didn't have fancy problems like pcie
<Mis012[m]>
minecrell: you *could* mess with TZ source if you wanted to :D
<konradybcio>
simpler times
<minecrell>
Mis012[m]: So basically TZ takes over some parts of the Linux ARM SMMU driver and hardcodes things
<konradybcio>
well, "simpler"
<bamse>
konradybcio: yeah, imagine back then having the upstream kernel and dt that we have today
<konradybcio>
before ufs happened
<konradybcio>
and kitakami suicidal emmc
<minecrell>
Mis012[m]: I guess but I don't see an immediate advantage of doing that (other than to make things slightly more insecure properly)
<minecrell>
Mis012[m]: Although I am curious if the PM8916 RTC is actually writable and TZ just locks that for who knows what reason
<minecrell>
I should try at some point
<Mis012[m]>
I wouldn't be surprised
<bamse>
konradybcio: for years i was told that "when ufs comes it will remove the need for all these file system bugs"...so don't know what you're talking about ;)
<Mis012[m]>
probably to prevent one core from doing time attacks on other cores
<konradybcio>
ahahah
<konradybcio>
famous last words
<minecrell>
Mis012[m]: iirc I saw somewhere that the RTC writable thing is assigned to the modem
<Mis012[m]>
sed
<Mis012[m]>
should be owned by Linux
<Mis012[m]>
as should GPS
<bamse>
minecrell: yes, the pm8916 rtc has registers for writing the clock...and the security configuration prevents apss from writing those registers
<Mis012[m]>
they have the hw framework to prevent modem from accessing GPS, and they instead route GPS through modem -_-
Daanct12 has joined #linux-msm
<bamse>
Mis012[m]: don't you need firmware to decode the gps data? do you really want to do that in linux?
<minecrell>
bamse: Seems like a strange thing to do but I guess the reason Mis012[m] mentioned makes sense ("time attacks on other cores")
<bamse>
minecrell: that's the hand-wavy reasoning that i've gotten every time i've complained about it
<Mis012[m]>
but then modem shouldn't have rw either
<bamse>
minecrell: might be that there's a real reason, but everyone is happy with that one
<bamse>
Mis012[m]: unless you run said software on the modem cpu
<Mis012[m]>
I mean for time
<Mis012[m]>
(rtcú
<Mis012[m]>
* (rtc)
<Mis012[m]>
if Linux doesn't need rw, why does the modem
<bamse>
ahh, right...
<bamse>
but it might be a cdma requirement...because for that the system clock must be in sync in with the network
<Mis012[m]>
being able to PWN Linux is probably also a requirement of one of these specs, and I sincerely hope that's not implemented
<bamse>
it's better today
<bamse>
10 years ago there was nothing preventing the modem from snooping or just stomping over the linux kernel memory
<Mis012[m]>
bamse: on msm8916, I guess there is only one DSP... but maybe the SSC core could deal with GPS, instead of the modem core?
<Mis012[m]>
or is the rationale that it's minimal attack surface, because the modem can get your position anyway... -_-
<bamse>
Mis012[m]: is there a ssc in 8916?
<Mis012[m]>
nag
<Mis012[m]>
* nah
Danct12 has quit [Ping timeout: 480 seconds]
<Mis012[m]>
msm8998 also has GPS routed though modem afaik
<Mis012[m]>
and probably same everything newer
<Mis012[m]>
* and probably same for everything newer
<Mis012[m]>
*through
<minecrell>
bamse: I just hope the reason for having the RTC read-only is better than the one they have for having hyp locked up. Because I'm like 95% sure Qualcomm's hyp does nothing useful at least on 8916, especially for security
macc24 has joined #linux-msm
steev has joined #linux-msm
<Mis012[m]>
even on msm8998 you could probably migrate most of what it does to TZ
<bamse>
minecrell: i wish i knew the answer to both of those questions
<bamse>
minecrell: i mean, really knew...
<Mis012[m]>
<bamse "10 years ago there was nothing p"> I'm not afraid that the hw doesn't allow locking it down, what concerns me is that the specifications often have some ugly requirements regarding leaving backdoors in the modem fw
<bamse>
Mis012[m]: it does, because we had to lock the modem out of linux on 8974 during development...
<konradybcio>
should have just put linux on the modem too /s
<bamse>
Mis012[m]: so a properly configured tz should prevent the modem from just stomping (or snoopign) on linux
<Mis012[m]>
properly configured yes
<Mis012[m]>
the one that ships? well...
<bamse>
konradybcio: never tried the modem, but we booted linux on the adsp on 8974...
<konradybcio>
erm isn't that the same physical chip?
<bamse>
Mis012[m]: we kept that on the sony devices...but i don't know how things has been setup since then
<bamse>
konradybcio: no, 8974 has one hexagon for modem and a different hexagon for adsp
<bamse>
konradybcio: i think 8916 is the only one i've poked at where the same hexagon runs both modem and audio firmware
<Mis012[m]>
SSC is the third hexagon and cDSP is the fourth
<Mis012[m]>
though SSC has quite a bit more going for it
<bamse>
Mis012[m]: and on 8974 i think "ssc" ran on the adsp
<konradybcio>
imagine 8974's coprocessor running linux but the main AP still having no way of talking to the iommus, how ironic xD
<Mis012[m]>
bamse: and there were no special pins that are a nightmare to access from Linux
<bamse>
Mis012[m]: i said we ran linux, not that we got linux to do anything useful ;)
<minecrell>
bamse: yeah the funny thing is that they seem to have "downgraded" 8916 to have just one hexagon after they still had two in the predecessor 8226
<konradybcio>
mis012 I just got a big brain idea on why you had to read twice from ssc on 8998
<minecrell>
In many ways 8226 is more advanced than 8916 for some reason
<konradybcio>
BSP might have had one read in the secure world parallel to the one in userland
<minecrell>
although, not that I mind
<bamse>
minecrell: probably cost effective
<bamse>
and more power efficient
<Mis012[m]>
<konradybcio "mis012 I just got a big brain id"> some clocks or something went haywire
<minecrell>
bamse: yeah I don't think it makes much of a difference for most use cases
<minecrell>
Actually I personally prefer the direct audio path DB410c uses, rather than all this qdsp6 mess
<Mis012[m]>
+1
<konradybcio>
bamse have you ever got display to work on rhine on mainline back at sony though?
<minecrell>
I'm not sure why this is even possible on all 8916, perhaps a side effect of merging the hexagon
<konradybcio>
i spent... ...a long time trying to get honami to display anything, but it kept saying no
<bamse>
minecrell: i prefer the adsp based one, just because it works on more targets, but the db410c in itself was nice to get working
<bamse>
konradybcio: rhine is 8974 right?
<konradybcio>
yep, z1/z1c/z ultra
<konradybcio>
the ones without cont_splash :/
<Mis012[m]>
it would sure be nice to have a way to not route audio through modem that is not meant for the modem's ears
<bamse>
konradybcio: i think we only did display on the devboard and on castor(?)
<konradybcio>
yeah castor on pmos uses your 4.3 kernel
<konradybcio>
kinda sad that it never got upstreamed
<Mis012[m]>
also controlling modem's ability to read microphone when not in a call would be noice
<konradybcio>
but then not many people have this device anymore and it's impossible to find on ebay-ish sites
<Mis012[m]>
<Mis012[m] "also controlling modem's ability"> I wonder if this stuff can be done with XPUs
<minecrell>
bamse: Both works on 8916 but the direct audio path is simply much "cleaner". Without the firmware inbetween you can actually properly control sample rates, latency etc
<minecrell>
bamse: I talked to someone who uses one of the 8916 smartphones as some kind of music instrument. They had to play with sample rates and latency a bit and I think qdsp6 would have been really frustrating for them
<bamse>
konradybcio: hmm, i have pictures of quake3 running on castor and leo is running xfce
<minecrell>
I mean, unless you are qcom customer and can use all the magic tools to adjust adsp configuration I guess
<konradybcio>
leo is shinano and this one had cont_splash already afaik
<bamse>
minecrell: right
<bamse>
konradybcio: well it was the same kernel...just different dtb
<konradybcio>
the thing is, if you have cont_splash all the regulators and clocks necessary are left on by the bootloader
<bamse>
konradybcio: i don't remember what obstacles the bootloader provided us
<konradybcio>
and rhine has some who-knows-what hardware "design choices"
<bamse>
konradybcio: but didn't we have that on all the sony devices?
<konradybcio>
yes and no
<konradybcio>
tone has a sane display setup
<konradybcio>
but yoshino does not
<bamse>
tone and yoshino are newer and use a less custom boot loader
<konradybcio>
well that too
<konradybcio>
up until yoshino, including yoshino, you need a whole lot of downstream dt nodes to enable cont_splash
<bamse>
ahh right, that crap
<konradybcio>
tone is a funny one, because it does not require anything if you coldboot it but does if you choose to fastboot boot
<konradybcio>
but then it can set up all the things from linux so it doesn't matter
<bamse>
konradybcio: on my laptop i had to write up a patch that shoots down all the configuration of the mdp, because it conflicted badly with how linux set things up
<konradybcio>
i wonder if that could fix edo
<konradybcio>
because the current situation is ehh.. very sad:)
<konradybcio>
do you have it up somewhere perhaps?
<bamse>
the biggest problem i had was that the bootloader uses CTL_0 to output the boot splash on INTF_5...but linux picks CTL_2...so i have to shoot down the first data path
<bamse>
and then there was a few registers here and there that needed further configuration
<konradybcio>
oh no i see a couple more hacks there :P
<bamse>
working on cleaning that stuff up
<konradybcio>
but then if I have the DSI display configured by the bootloader and then I try to use the same DSI display, should this even affect me?
<bamse>
but most of these things stems from my laptop not having dsi...otherwise we typically ends up with configuration similar to what the bootloader has
<bamse>
so the one thing we've had to spend time on for dsi on recent platforms is that they typically use dsc
<bamse>
vinod has patches on the list for that
<konradybcio>
qcom,compression-mode = "dsc";
<konradybcio>
oh I totally didn't overlook that
<konradybcio>
gonna try them out then soon, thanks for suggesting that heh
<konradybcio>
but that does not explain the angry clock situation
<Mis012[m]>
we have dsc now? need to hook bylaws then
<konradybcio>
but then it's not the first time that mdss rcgs are not responding and many platforms work fine with that