rauji_ has quit [Remote host closed the connection]
pevik_ has joined #linux-msm
<animist>
flto, hi, I'm trying to test a TPG on SM8250 CSI running your camss changes, however I get no luck so far, do you know if it is supposed to be working?
<Marijn[m]>
<abhinav___> "Marijn: agree with dmitry..." <- Fine by me, mdp5 is working for us and my top priority is anyway cmdmode panels on newer SoCs. That is, if I can find time at all to play with mainline, life is busy as ever :(
<flto>
animist: I did not try TPG on sm8250, but IIRC TPG didn't change from sdm845 so it should probably work. maybe bryanodonoghue tried it?
<aka_[m]>
bamse: what's your opinion on using soc specific compatible on different soc dts if both share same data?
<aka_[m]>
Like one for apcs mailbox.
<aka_[m]>
Multiple socs from some era reuse same offset for IPC interrupt and yet they have different compatibles but with same .data
pevik_ has quit [Ping timeout: 480 seconds]
<calebccff>
bamse: I heard you have some patches for dp alt mode on 845?
<bamse>
aka_[m]: i don't like the cases where you end up using compatibles with other platform names in them
<bamse>
aka_[m]: the preferred way is compatible = <platform-specific>, <generic>
<bamse>
aka_[m]: the problem with apcs is that i've not been able to come up with a generic compatible name
<bamse>
aka_[m]: the reason for this is that if we run off the generic compatible, but later need to have platform-specific behvaior, we can do that with such a model
<bamse>
aka_[m]: if we just use some other specific compatible we don't have that future flexibility
<bamse>
calebccff: well, that's unfortunately not the entire truth
<bamse>
calebccff: i have changes to the tyepc framework to support multiple typec_{mux,switch} instances (e.g. qmp + fsa4480), i have patches to qmp for controlling the usb/dp mux in the phy and i have patches for propagating hotplug events into qcom displayport driver
<aka_[m]>
well, i asked because at some point we will have multiple patches to just submit one compatible which will point to same data in driver, for example 8976/8937 use same one and it leave us sending patches and waiting some unknown time just for adding compatible.
<bamse>
calebccff: i then have a type-c controller driver for sc8180x & sm8350, which invokes those interfaces
<bamse>
calebccff: but pretty much what's missing for 845 is the typec controller, to do the PD dance and let us know when to switch altmode etc
<bamse>
calebccff: the plan was to try to land these patches once the merge window ends, and then perhaps see if i can wire it up on my 845 laptop. because it does typec handling in an external chip with an interface that seems quite similar to the pmic_glink notifications
<bamse>
aka_[m]: yes, that's the biggest reason for having a generic compatible
<bamse>
aka_[m]: typically qualcomm have one or more legacy-like register layout and then they "stabilized" that into something where it happens to always be the same...but i wasn't able to spot any such pattern in apcs
<z3ntu>
I also have a different question, sm6350 downstream ("lagoon") contains pmk8350 pmic on spmi bus addr 6 ("sid" I think it's called). Kind of a problem because mainline already contains pmk8350.dtsi on addr 0 that's used by sm8350 and sc7280
<calebccff>
bamse: thanks, I'll take a look. I was hoping to be able to hook up dp alt-mode on the SHIFT6mq, I had a go at writing some DT for it but I couldn't figure out what driver bits were missing. Do you know if it will require support in the smb2 / pd driver too?
<lumag_>
calebccff, yes. You will have to write tcpm driver for the smb2 bits
<lumag_>
bryanodonoghue, did that for sm8250/pm8150b
<calebccff>
lumag_: ah, fun! the smb2 driver really is something else :D hopefully that won't be too hard to get going
<calebccff>
I saw the sm8250 patches, from what i can tell it's quite different hardware
<bamse>
z3ntu: on sm8150 i have a single pm8150, on sa8155p we have two pm8150, on sa8540p i now have 4 pm8150
<z3ntu>
excuse me, 4x pm8150 on one board?
<bamse>
that's the way we roll in the shire
<bamse>
calebccff: yeah, they seem to have reworked those hardware blocks again after 845
<Mis012[m]>
well, they are just chips...
<Mis012[m]>
there is no real reason why you can't have any amount of them that you please
<bamse>
Mis012[m]: right, but it feels like an odd choice
<z3ntu>
LOL. My pmk8350 only really contains rtc clock, not much other useful things (at the moment at least)
<Mis012[m]>
bamse: you could probably even find some non-qcom SPMI slave chips to shove in there
<lumag_>
z3ntu, adc for thermal monitoring?
<lumag_>
bamse, wow, 4xpm8150
<Mis012[m]>
and mainline shouldn't really assume that you will not, even if it would be weird to do so
<bamse>
z3ntu: i've already lost track of which board was which, but i have a couple of boards on my desk with 6 and 7 pmics...and at least 2 of them has pmk8350 somewhere in on the spmi bus, so i bet i have the same problem as you
<z3ntu>
lumag_: yes, alsos vadc & adc-tm, gpios and clkdiv but the gpios don't seem to be used, and who needs thermals :P
<lumag_>
:-)
<bamse>
Mis012[m]: mainline doesn't assume, the problem is that the way we write the dts for pm8150 encodes the address on the bus throughout the representation of the pmic
<Mis012[m]>
bamse: what determines the address of the chip on the SPMI bus?
<bamse>
Mis012[m]: so if you have a pm8150 on address 0, the dts for that is scattered with 0s and 1s to, and if you wire the pm8150 differently it will show up on address 2 and 3, but as we do it today that requires a different dts snippet
<Mis012[m]>
uh hm, that's not great
<bamse>
Mis012[m]: we don't have a way to say "import the pm8150 dts subtree, on address 2 and 3"
<bamse>
Mis012[m]: which hasn't been much of a problem until now, we've just duplicated the information into two files
<Mis012[m]>
but device tree fragments can do that, right?
<bamse>
z3ntu: right, but would be nice if we had a dtsi that fully described the pmk8350 and then if you just want the rtc you can enable that
<bamse>
Mis012[m]: aren't those just for dynamic loading?
<Mis012[m]>
bamse: duplicating the information sounds pretty ugly...
<z3ntu>
Do all of these pm8150 or pmk8350 have the same feature set at least or are there like different variants again that only support parts? My device downstream prints "PMIC@SID6: PMK8350 v2.0.0.32 options: 0, 0, 0, 0"
<bamse>
Mis012[m]: yeah, it was ugly but worked...but now i have a lot of pm8150s ;)
<bamse>
z3ntu: there are gpios on the chip, depending on how they are wired (high, low, floating) the chip will have different addresses
<Mis012[m]>
bamse: well, yes, they are just for dynamic loading, but I wonder if you could reuse the syntax
<bamse>
Mis012[m]: it's worth investigating...because we need something
<bamse>
z3ntu: so it's the same pmk8350, just with different address
<z3ntu>
ack, thanks for the clarification
<Mis012[m]>
bamse: really how you seem to describe these chips with device trees is what AMD ought to do with their GPU IP cores xD
<bamse>
i think this was introduced around pm8150 or so, because i don't remember seeing it before
<Mis012[m]>
so I hope you can make it work
<Mis012[m]>
bamse: I assume you have seen the "these should be device trees" .h files that amdgpu carries?
<bamse>
Mis012[m]: nah, i've never actually looked at what they carry in there
<Mis012[m]>
bamse: massive .h files with defines for addresses and bitmasks
<Mis012[m]>
bamse: what I would really love to see would be device tree overlays in PCI ROMs to replace atombios :P
<Mis012[m]>
bamse: but more importantly, I just realized, isn't it pointless to have runtime pm in my ssc bus driver?
<Mis012[m]>
I can't imagine anything good happening if I dynamically remove the power...
<Mis012[m]>
these are what I currently power on/off dynamically
<Mis012[m]>
and I'm starting to think that it doesn't work because the premise doesn't check out
<Mis012[m]>
if that driver is loaded, then I always want to have those powered...
<bamse>
z3ntu: but just to be clear, just because i have the same problem doesn't mean i have any good ideas, so don't just wait for me to solve this ;)
<bamse>
Mis012[m]: it's plausible that you want to be able to turn off power when you're not using the ssc hardware...but that depends on the use case
<bamse>
Mis012[m]: based on our previous discussions it sounds quite likely that they will be always-on thouh
<bamse>
though*
<Mis012[m]>
bamse: well... how can I reasonably know if I want to use it or not
<z3ntu>
hacky idea is #include "pmk8350.dtsi" &pmk8350 { reg = <0x6 SPMI_USID>; };
<z3ntu>
works for my use case but I doubt we want this upstream
<calebccff>
z3ntu: the node would still be called `pmk8350@0` too right?
<Mis012[m]>
bamse: yeah... at this point I think if you want the IP block to be powered off, you probably don't mind unloading the driver
<Mis012[m]>
calebccff: technically that part is purely decorative, but it can't be the same if you have multiple pmk8350@X nodes
<Mis012[m]>
hmm, it looks like the fragments actually don't deal with this issue
<Mis012[m]>
<z3ntu> "hacky idea is #include "pmk8350..." <- it actually can't have a phandle either
<Mis012[m]>
bamse: what would be the proper way to get rid of the magic here?
pevik_ has joined #linux-msm
<Mis012[m]>
I can't really do offsets since neither of these is part of the ssc block (nor can it be, since the ssc block is not addressable until these are configured correctly)
flowriser has joined #linux-msm
<Mis012[m]>
hmm, seems that the last one is in this range
<Mis012[m]>
well... it seems pointless to push a whole linux tree because of three patches
<Mis012[m]>
calebccff: do you have the FLAT or should I send one your way?
<Mis012[m]>
actually not FLAT, sadly, but iirc I have an equivalent that is a bit less readable
<calebccff>
what's FLAT?
<calebccff>
iirc some devinfo changes are needed to allow access to the SSC registers?
<Mis012[m]>
an artifact of the process of making an SoC
<Mis012[m]>
it's a register map for the entire address space
<calebccff>
oh neat, would be nice to get one for SDM845
<Mis012[m]>
calebccff: not devcfg actually... what I do now is that I binary patched the hypervisor's SMMU config data structure array
<calebccff>
ah... fun
<Mis012[m]>
and all except except one of the pesky registers that I need to touch have notthing related in the same SMMU addressing unit...
<Mis012[m]>
so it's almost side effect free
<Mis012[m]>
*nothing unrelated
<Mis012[m]>
as in, you could combine this with removing the permissions from the SSC hexagon core so that there is no cross-talk potential, and actually distribute it to end users as an alternative signed hypervisor
<calebccff>
you should write this up somewhere so this info isn't lost :P
<calebccff>
that said, existing devices with secure boot enabled will never get support for this... it's good research nonetheless
<Mis012[m]>
yeah... I should have done that back when I was doing it :P
<Mis012[m]>
calebccff: existing devices could get an alternative hypervisor binary with *almost* no side effects, so it your OEM isn't a total dick...
<Mis012[m]>
but almost is a key word sadly
<Mis012[m]>
*if
<Mis012[m]>
calebccff: also I realized that while it would be nice to make a FOSS fw for the hexagon core, there is no FOSS toolchain for hexagon v6...
<calebccff>
i mean, no OEMs are going to ship that
<calebccff>
yeahh, since hexagon got quite locked down there's just no devices to use to work on it
<Mis012[m]>
that's not even the issue
<Mis012[m]>
I'll be setting up SWD
<Mis012[m]>
but because LLVM killed the paradise that GCC fought to establish where you could actually have a FOSS toolchain for any random oddball CPU...
<Mis012[m]>
you're stuck with using a proprietary toolchain, which somewhat kills the point of having foss firmware
<konradybcio>
we can use omit-if-no-ref for pmics that can appear on multiple sids
<konradybcio>
and then enable for example pm8150_sid1 in board dt
<Mis012[m]>
calebccff: it's not a FLAT, but it has all the same information
<konradybcio>
brave thing to share in a room with qcom employees lol
<Mis012[m]>
qcom employees != qcom lawyers
<Mis012[m]>
it's not like you can copyright that
<Mis012[m]>
they would sooner make a patent case than a copyright case...
<Mis012[m]>
and remember that someone at qcom sneaked in a section about RAM training into the 8x16 trm
<Mis012[m]>
which is sadly yet to be utilized
<Mis012[m]>
calebccff: but I am making the code cleaner as we speak fwiw
<Mis012[m]>
konradybcio: I would obviously not be sharing it if I ever signed an NDA for it, since the entire purpose of NDAs is to criminalize sharing of something that you literally can't claim copyright on :P
<anholt>
anyone have a clue why updating to 5.16 would make db410c stop probing ci-hdrc?
<flto>
Mis012[m]: upstream llvm actually has good hexagon support (except they didn't upstream support for the special system-level instructions, which change more often between hexagon versions. but they are trivial to add support for)
<Mis012[m]>
flto: even for v6?
<flto>
yes, I'm using it with v67+hvx in particular
<Mis012[m]>
wow, how did I miss that
<konradybcio>
how does one go about loading linux on it?
<konradybcio>
you got my interest too heh
<Mis012[m]>
konradybcio: linux *definitely* only supports v5
<konradybcio>
fo rnow
<Mis012[m]>
might want to replicate booting in on v5 first :P
<Mis012[m]>
also the official support uses some kind of hypervisor on the arm cores iirc
<konradybcio>
i have an ancient piece of otherwise e-waste whose q6 may be faster than its arm core..
<Mis012[m]>
I don't think it's called q6 if it's v5 :P
<konradybcio>
2010 device with a 2009/10 soc sounds eld enough
<Mis012[m]>
konradybcio: what SoC?
<konradybcio>
7227 non-a
<konradybcio>
msm7k platform
<Mis012[m]>
some pre-8xxx SoCs actually use the modem core as the boot processor iirc
<Mis012[m]>
but I think those don't use hexagon
<Mis012[m]>
you can hit up swiftgeek
<konradybcio>
i think it doesn't only stand for pre-8xxx
<Mis012[m]>
8974 uses RPM as it's boot processor
<minecrell>
anholt: do you have a dmesg log or something?
<minecrell>
I'm 99% sure it worked fine on the earlier -rc at least
pevik_ has quit [Quit: Lost terminal]
lumag_ has quit [Remote host closed the connection]