07:42 <krzk> konradybcio: z3ntu: I don't know who came with the idea of aliases for socs - milos - but good luch in defining the concise schema for matching the preferred compatible style. :/

07:43 <krzk> plus, knowing the history of SoC families and SM/QCS/QCM variants in qcom, you really need to explain what these cryptic names mean

07:45 <krzk> Last problem is also coming because I saw first tlmm patch for milos and no SoC patch (no bindings), so that's why it is surprising

07:53 <krzk> BTW, I marked all sm7635 v1 patches in DT patchwork as supersed, even though not all of them were superseded now, but I guess that's what is going to happen

08:43 <konradybcio> krzk the point of using the codenames is no never have to refer to (S[AM]|QC[SM])[0-9]{4}(X|XP|)|(pro|lite) again

08:45 <konradybcio> there's some obvious tradeoffs with that, like you mentioned, but we at least get rid of the variants, which is useful when a platform has like 10..

08:49 <krzk> Variants is your choice... you will have them here as well, just differently named

08:50 <krzk> If going this path - I guess there will be a big list of codenames in the bindings enforcing naming rule?

08:50 <krzk> Or you want to abandon that binding, hoping people will get it right (hint:they don't)

08:53 <Mis012[m]> konradybcio: are these the proper die codenames though

08:55 <Mis012[m]> qcom has a lot of codenames, and some of them still refer to variants with same die and minimal fusing differences

11:15 <z3ntu> krzk, konradybcio: Can I continue sending v2 of my milos/sm7635 patches with the renaming? Or wait until the milos pinctrl discussion is settled? I've got a few v2's ready for sending

11:23 <krzk> z3ntu: if you implement my comments about commit msg you can go, but if you send everywhere the same as pinctrl,it might get back to you

11:25 <z3ntu> krzk: So say "on the Milos Platform (e.g. SM7635)"?

11:26 <z3ntu> I can also add "Snapdragon 7s Gen 3" somewhere if that helps

11:27 <krzk> z3ntu: marketing names don't help me, although some people outside like them. I just want to see the real soc model name, so I will be sure this is not a family.

11:29 <z3ntu> From what I've been told Milos is not a family, it's a chip which has multiple model numbers. I got this from Konrad:

11:29 <z3ntu> >

11:29 <z3ntu> sm6650p = milos but sm7635 also = milos (because they're the same hardware)

11:32 <krzk> well, as we were told by qcom with great sa8775p/qcs saga and idea of renaming compatible everywhere, same hardware and different firmware means different compatible, so you cannot go with milos alone

11:32 <krzk> srsly, it's like everything from sa875p/qcs was forgotten... konradybcio really?

11:37 <krzk> (z3ntu so maybe wait with the rest of the patches till we clarify it and you got at least some ack from DT maintainers)

11:37 <z3ntu> I mean sc7280 is also not easy since there's sc7280/qcm6490/sm7325 with different firmwares around, e.g. qcm6490 RB3Gen2 (newer(?) firmware) is different to qcm6490 FP5 ("Linux Android" firmware, older(?)) is different to sc7280 chromebook (Google's different firmware). But nothing there is specific to sc7280 vs qcm6490, you can probably mix-n-match the firmwares on the different model numbers if they were available

11:37 <krzk> I imagine renaming it back and forth is frustrating :/

11:37 <z3ntu> I've already renamed everything in my local tree 🙃

11:39 <krzk> z3ntu: yes, sc7280 is another example, buht it is also clear - customer has device with sc7280 means it comes with given firmware. Maybe you can load different firmware, but I argue that should not matter for the naming. If you load differen tfirmware to same hw, you get different hardware, because for Linux firmware is the hardware now.

11:39 <krzk> Absolutely the best example is the sa8775p/qcs saga, huge discussions spanning over multiple meetings and emails concluding that different in firmware means DTS is 100% incompatible.

11:40 <krzk> So you cannot use the same compatible for both devices.

11:40 <z3ntu> yeah, I didn't follow those chips at all, so no clue what was/is going on there

11:40 <krzk> They basically manage all power related resources completely different, based on firmware.

11:42 <konradybcio> krzk no.. my explanation omitted the scmi problem

11:42 <konradybcio> because that's orthogonal to the issue i described

11:43 <krzk> sounds like exaggerated issue, but touching the same problem. Same hardware, different model numbers, different compatible.

11:43 <krzk> sm6650p and sm7635 - same hardware? yes? same model, yes? so different compatible.

11:43 <krzk> s/same model, yes?/diffrent model, yes?/

11:44 <konradybcio> on my way to define a separate compatible for each cpugpunpu speed bin combination for every platform then..

11:46 <Mis012[m]> compatible is mainly for an ip block, which in many cases is accessed the same irrespective of fw

11:46 <Mis012[m]> the top level compatible is not used by anything anyway

11:47 <konradybcio> the chip name has absolutely nothing to do with the firmware it runs, by the way.. you can totally load sc7280-chrome firmware on any other flavor of the chip (and vice versa) - same with auto parts.. it was only a poor choice to tie the software contract to a model number

11:48 <Mis012[m]> well, technically the xbl_sec checks for a cros fuse

11:48 <Mis012[m]> the cros one that is

11:49 <konradybcio> maybe.. in any case, there's also sc7280-windows, with a firmware more aligned to the android kind..

11:49 <Mis012[m]> and qcom won't just let you do custom fusing, so you better hope they have a model number with something you like

11:50 <Mis012[m]> but yes, imho there should be a qcom,kodiak compatible for the IP blocks that are accessed directly from Linux so fw doesn't matter

11:51 <Mis012[m]> but then again, you can't even do that for smmus

11:51 <Mis012[m]> so you will have half the peripherals with different compatible

11:52 <Mis012[m]> though smmus are not soc-specific compatibles iirc, so that one's fine

11:54 <Mis012[m]> I guess there are not that many things that wouldn't be the same between proper cros fw and Linux in EL2 on WoA fw

11:55 <Mis012[m]> and yeah, WoA 7280 and android 7280 is technically different fw although it's similar

11:55 <Mis012[m]> konradybcio: speaking of scmi, could you tell qcom to make rpm talk scmi directly :P

11:55 <Mis012[m]> scmi to tz and old stuff from tz to rpm seems redundant

12:06 <krzk> konradybcio: there is ongoing rule we do not define compatibles per bins and that's not a bin here

12:07 <krzk> ongoing -> I meant existing and already expressed on mailing lists

12:08 <krzk> konradybcio: and if you really do not connect model name to FW, then it is also fine - you have milos-scmi and milos-whatever front compatibles.

12:13 <krzk> Mis012[m]: it is not true that top level compatible is not used. It is actually used in multiple places in kernel and bootloaders.

12:14 <krzk> And should be used much more but bootloader people always say it is too dificult to compare strings

12:14 <krzk> Also look at recent Casey pull req to dtschema - reimplementing compatibles :/

12:15 <Mis012[m]> right, it should be used in bootloaders, never saw that in the wild though :P

12:15 <Mis012[m]> krzk: if bins shouldn't have special compatibles then what's this https://github.com/torvalds/linux/blob/b4911fb0b060899e4eebca0151eb56deb86921ec/arch/arm64/boot/dts/qcom/sm7325.dtsi

12:16 <krzk> Mis012[m]: why do you ask me about some random code somwhere? Ask the author what is this.

12:16 <Mis012[m]> I heard it said that it reports a different cpuid

12:16 <krzk> Is this a bin? Was it communicated that it was a bin?

12:16 <Mis012[m]> but it's definitely same die

12:16 <krzk> Well, why you did not comment on the patch for that :/

12:17 <Mis012[m]> saw it too late

12:17 <krzk> There is no point to discuss prior commits, somehow recently third time bring this up

12:17 <krzk> I meant, people bring this up... I saw commit foo bar, what is this. No clue.

12:18 <Mis012[m]> well, I feel like some of the people reviewing it must have known it's the same die, but maybe not

12:18 <Mis012[m]> if it's unintentional then fair enough

12:19 <krzk> There is no point to discuss if this was intentional or not.

12:19 <Mis012[m]> well, can a speed bin that somehow changes cpuid have a different compatible

12:19 <krzk> plus that is not different bin, because 670 is a different core

12:20 <Mis012[m]> weird how they managed that on the same exact die though

12:20 <krzk> Mis012[m]: again, what is the point to discuss previous commit? you will not get the answer for new commit from that

12:20 <konradybcio> not sure if you want to get into the kryo can of worms..

12:21 <Mis012[m]> I mean, I would like kryo naming in mainline to die even if just based on the fact that it caused that

12:21 <Mis012[m]> unless it's actually considered correct

12:21 <Mis012[m]> but I think newer stuff is using it less?

12:22 <Mis012[m]> krzk: it just reminded me of that, and I wonder if it's intentional

12:22 <konradybcio> newer parts (~8550 onwards) seem to use vanilla arm cpus, at least looking at the reported MIDR_EL1 partnum

12:23 <Mis012[m]> well, arguably older parts also used vanilla arm cpus and just lied about it

12:23 <Mis012[m]> or maybe not, but clearly qcom can't be trusted on that matter

12:24 <Mis012[m]> at the very least they were close enough that there should be both compatibles

12:24 <z3ntu> fwiw sm7635 datasheet says "Qualcomm® Kryo™ CPU 7-series built on Arm Cortex technology"

12:25 <Mis012[m]> it's definitely based on specific cortex cores, not sure whether it's supposed to be public which ones but I saw that info somewhere (maybe wikipedia?)

12:25 <Mis012[m]> the question is if there are ANY changes to them, seeing as qcom seems to think a bin means different core

12:26 <konradybcio> yes, downstream has some debug drivers where some uncore peripherals seems customized

12:26 <Mis012[m]> fun

12:26 <Mis012[m]> well, I guess it doesn't matter since can't fix it retroactively and new stuff is sane

12:26 <konradybcio> the last message was with some kryo-advertizing-qcom-manufacturer-id in mind, cant remember which one

12:27 <konradybcio> its been a couple yeras

16:57 <aka_[m]> konradybcio: any eta on slotsuffix merge in rmtfs?

16:57 <aka_[m]> to main branch obv

17:42 <bamse> krzk: the problem with the current naming scheme is that it's not based on either hardware or software variations

17:42 <bamse> krzk: and the push for changing to use codenames (the real codenames) is mine

17:45 <bamse> krzk: "milos" is the name of the soc, sm7325 is one bin of it