<bamse>
Mis012[m]: hehe, acpi definitely has it's benefits to dt
<bamse>
Mis012[m]: like for your ssc bus, with acpi you would just hide all that stuff from the OS
cxl000 has quit [Remote host closed the connection]
cxl000 has joined #linux-msm
svarbanov has joined #linux-msm
<steev>
Mis012[m]: we don't know what chip it is :(
<steev>
that's part of the issue
<steev>
the acpi tables claim it has a compal of some sort
<steev>
then again, they also claim the battery is a PABAS0241231 and it's definitely not
lumag_ has joined #linux-msm
pevik_ has joined #linux-msm
<Mis012[m]>
bamse: but hiding stuff from the OS is ugly... one of the points of an OS is to have drivers for hw
<Mis012[m]>
steev: can't you just open up the device and read what is printed on the chip?
<Mis012[m]>
surely they didn't go through the trouble of sanding it off
frytaped has joined #linux-msm
frytaped has quit [Quit: frytaped]
<bamse>
Mis012[m]: yeah, but if you instead use the word "abstract" instead of "hiding" then it's probably a nice thing
<Mis012[m]>
you know who else uses the word abstract?
<Mis012[m]>
android in HAL
<Mis012[m]>
ACPI isn't even MEANT to do anything other than board-level hacks
<Mis012[m]>
it's bad enough that it's designed for hacks, but abusing it for SoC-level hacks is really too much...
<Mis012[m]>
bamse: qcom also uses TZ for abstraction, which is even worse because you can't easily do it properly then without replacing TZ
<Mis012[m]>
"stuff for hw abstraction" is one of the most cited short answers for "what is an OS"
<Mis012[m]>
clearly it's the OS's job
<bamse>
minecrell[m]: what's the status on enabling cpr on 8916?
<minecrell>
bamse: I have a set of hacky changes that seems to work (although I can't say that there is really any noticeable difference). I got stuck with some complicated open design questions back then (not functional ones, but more "how to solve this properly upstream"), and haven't worked on it again so far
<bamse>
minecrell: the question about the downstream clock-regulator relationship?
<minecrell>
bamse: One of the main open questions was "who enables the power domain for the "required-opps" in the CPU opp table". On qcs404 this works because the cpr power domain does not care if it's on or not. But I also added a required-opp for qcom-rpmpd which doesn't do anything until it's enabled
<bamse>
minecrell: isn't the cluster idle code doing that?
<minecrell>
bamse: That's separate power domain. Also, it doesn't actually make sense to enable/disable the power domain because the CPU needs it as long as it runs, so the CPU can impossibly be responsible to disable it
<bamse>
hmm okay, i need to dig into the details of this stuff again it seems
pevik_ has quit [Ping timeout: 480 seconds]
<minecrell>
bamse: I think it might be easiest to make MSM8916_VDDMX_AO simply always-on. It's the active-only variant so I think RPM will handle it automagically on CPU idle
<bamse>
minecrell: that seems quite reasonable
<minecrell>
Sadly there doesn't seem to be something like regulator-always-on for power domains, that would have been convenient
<bamse>
minecrell: there's a bit we can set in the driver, if we think that's the right thing to do
<bamse>
although it's a power-domain, so i think the core will be helpful and turn it off as we're trying to suspend
<minecrell>
bamse: hm, I'd expect it leaves it on if it's declared as always-on?
<bamse>
minecrell: i heard you liked curve balls, so here's a curve ball for your curve ball...
<Mis012[m]>
bamse: am I expected to reply to reviews even when my next revision addresses them? it seems like not doing that causes stall...
<steev>
Mis012[m]: i don't know where the chip is, is the problem, mainlyy
<Mis012[m]>
steev: well... if you go through all the large-ish chips...
<steev>
Mis012[m]: there's also the fact that i have a stripped screw so i can't open mine anymore
<bamse>
Mis012[m]: there's no need to "ack" feedback in a reply, if there are questions asked it might be a good idea to answer those - unless the answer is clear from the new post
<steev>
there isn't a teardown on ifixit either
<Mis012[m]>
steev: drill out the stripped screw? idk, seems weird to give up on opening a device
<Mis012[m]>
bamse: oh, *reply*, the magic word... so I need to use some git-send-email feature to have the new version linked to the old one?
<Mis012[m]>
steev: there are other ways to get a stripped screw out
<steev>
i'm aware
<steev>
I believe it’s on the “underside” of the board, and unfortunately, as mentioned, this is my daily machine and I didn’t wanna take it completely apart
<bamse>
Mis012[m]: there's no need to have a in-reply-to the old patch, use "-v 2" when you git format-patch to generate [PATCH v2] ...
<steev>
I have been thinking of grabbing another one off eBay, that is “for parts only” and then I would have less concern about breaking it
<Mis012[m]>
bamse: phew, it's just that the frequency of replies on the series used to be pretty high and now it's silent, and I was getting flashbacks from upstreaming the zinitix touchscreen driver
<Mis012[m]>
steev: it's on the underside in my daily driver lappy, so I had to take it apart almost completely, but sadly it turns out it's one that I can't get a datasheet to
<bamse>
Mis012[m]: we had the merge window the past two weeks, which typically means much less response on new patches and then this week people are busy getting their patches onto the list for v5.18 ;)
<Mis012[m]>
bamse: it's fine, I'll find a way to keep myself busy... thinking about porting u-boot to msm8998
<Mis012[m]>
the other qcom ports seem to not use the same ugly blob that coreboot somehow allowed, so that's nice
<Mis012[m]>
on the other hand, it's meant as a second stage bootloader... :/
<steev>
Mis012[m]: i do appreciate you pointing out the ite chip, because i had no idea what i was looking for when i was looking for it
<Mis012[m]>
steev: well, honestly, I found it pretty quickly once I accepted that I have to look at the other side of the board xD
<Mis012[m]>
steev: the sad thing is that I don't even have a clue what instruction set ite8225e uses
<Mis012[m]>
and it doesn't seem trivial to figure it out, especially when it's code is scattered around the same SPI ROM as the eewEFI
<minecrell>
Mis012[m]: 8916 has "nice" docs for many things :p ("nice" is probably wrong word unless you put it in comparison with the void available for everything else from qcom)
<Mis012[m]>
it has a RAM training section, that's definitely pulled out of the "not even with NDA" docs :P
<Mis012[m]>
doesn't really sound like they are very open to people reading it :P
<Mis012[m]>
>The embedded controller contains industrial standard
<Mis012[m]>
8051 microprocessor
<Mis012[m]>
ok, so on one hand, you probably don't want your one to use 8051
<Mis012[m]>
programming that in C is pain, I've heard
<Mis012[m]>
on the other hand, if it also uses an 8051, this datasheet might be of more help
<Mis012[m]>
>Each hardware command can be processed by firmware optionally.
<Mis012[m]>
heh, would be really lucky if it turns out that you can just brick the fw and it will expose a hw API :P
<Mis012[m]>
minecrell: speaking of things I should try, porting Sound Open Firmware to hexagon :p
<minecrell>
Mis012[m]: eh lol
<Mis012[m]>
xtensa, hexagon, that would make two platforms that have their own instruction set :P
<minecrell>
Playing with the wcnss on 8916 should be actually possible, the registers are in the public HRD and I think it should be a standard ARM9 core with GIC, ARM timer and access to the peripherals
<minecrell>
I need to try booting something on it at some point
<Mis012[m]>
registers are also in the FLAT
<Mis012[m]>
minecrell: do you think handling a modem is in-scope for SOF? xD
<Mis012[m]>
since 8916 only has one hexagon
<minecrell>
dunno what FLAT contains but if it's just listings the docs are a bit better
<minecrell>
they have descriptions for the bits
<minecrell>
for some at least
<Mis012[m]>
it's basically a complete register map
<Mis012[m]>
with names for bitfields, usually
<minecrell>
Mis012[m]: Well, if you manage to build a working modem firmware
<minecrell>
This would be a giant, yet almost impossible achievement :p
<Mis012[m]>
minecrell: that's a job for RF people
<Mis012[m]>
and before that, we want to redefine everything that's sw configurable anyway :P
<minecrell>
sounds like SOF is for audio people then
<Mis012[m]>
well...
<Mis012[m]>
in a way
<Mis012[m]>
but you don't need to get audio licensed by FCC
<Mis012[m]>
did you know that PDFs can have attachments? :D
<minecrell>
bamse: Btw, do you have any more thoughts about https://lore.kernel.org/linux-arm-msm/Yac7rvxHhWld1%2Fs3@gerhold.net/? I think it's best to keep the bam-dmux node below the remoteproc. What I could do is change the remoteproc patch to only populate bam-dmux rather than everything below the remoteproc, so people don't accidentally "abuse" it without
<minecrell>
further discussion
<Mis012[m]>
glhf with that 8051 fw
<steev>
Mis012[m]: i had no idea. also bamse ^^
<Mis012[m]>
steev: in your case, it looks like the fw is just for the thing and for it alone, stored inside it's on-board flash... so hopefully the info in the other datasheet is enough to help you decompile the fw and start from there
<Mis012[m]>
sadly I'm not convinced that chromeos-ec can be compiled for 8051...
<Mis012[m]>
I wonder if it would at some point make more sense to make a small risc-v emulator :P
<Mis012[m]>
bamse: after looking at all the `SHADOW` registers in WCSS_WRAPPER, I'm starting to think it's pretty clear that SSCAON_CONFIG falls under one of the unsupported scenarios in SCALe Autoreg
<bamse>
minecrell: per your argumentation it would seem that ipa need/should be a child of modem as well...but only in some configurations
<bamse>
minecrell: that said, we have instances of memshare as well that needs to live somwhere, and they are tied to their respective remoteproc
<minecrell>
bamse: well, the difference is that IPA has own memory resources
<minecrell>
I suppose there we would need some kind of phandle
<minecrell>
Could potentially use the same for bam-dmux later if you would prefer to have it on top-level
<bamse>
minecrell: right, but in order to bind the wwan device to the same modem as the other nodes
<bamse>
minecrell: i don't prefer to have a random node somewhere with a phandle
<minecrell>
bamse: so, do you still have open concerns about the patch? :)
<bamse>
minecrell: i still have the fundamental concern about the other child devices coming and going based on the running state of the remoteproc
<bamse>
minecrell: but i presume we'd end up with similar semantics if we bolt the memshare driver there...
<minecrell>
bamse: I wonder if this is an implementation detail that shouldn't affect the device tree. We could unprobe BAM-DMUX with the remoteproc, but it would just make the implementation more complicated
<bamse>
minecrell: yeah, i _think_ you're right
hexdump0815 has joined #linux-msm
<minecrell>
bamse: I'm inclined to submit a v2 where I create a platform device explicitly for bam-dmux rather than using of_platform_populate(). This would make it more obvious that the way it's probed is a Linux "implementation detail", and we could still change the code to probe it differently later
<minecrell>
hexdump0815: cool, I barely remember it :)
<hexdump0815>
i tested it on a samsung gt510 and a motorola harpia and it works nicely for external keyboard, mouse and ethernet
<hexdump0815>
i used one of those otg hubs with three different settings for different tablets etc. and both require different ones, but then work very well and it looks like the device gets even powered this way without any charging/discharing activity on the battery
<hexdump0815>
so in the end quite nice for kind of a notebook mode for the samsung tab 1 9.7 ...
<hexdump0815>
tab a i ment
<minecrell>
hexdump0815: yeah, you can join the postmarketOS chats to find more persons using the tablet that way :)
<bamse>
minecrell: yeah, the problem with that is that we already have a bunch of the subdev stuff etc explicitly "probing"...so it's already ugly
<minecrell>
bamse: Well, at least it would be "consistently ugly" then :D