BobBeck has quit [Quit: Ping timeout (120 seconds)]
BobBeck has joined #linux-msm
BobBeck8 has joined #linux-msm
mort_6 has joined #linux-msm
gpiccoli_ has joined #linux-msm
alexeymin_ has joined #linux-msm
minecrell0 has joined #linux-msm
pg12 has joined #linux-msm
BobBeck has quit [charon.oftc.net coulomb.oftc.net]
gpiccoli has quit [charon.oftc.net coulomb.oftc.net]
minecrell has quit [charon.oftc.net coulomb.oftc.net]
x[m]1 has quit [charon.oftc.net coulomb.oftc.net]
pg12_ has quit [charon.oftc.net coulomb.oftc.net]
alexeymin has quit [charon.oftc.net coulomb.oftc.net]
MartinBotka[m] has quit [charon.oftc.net coulomb.oftc.net]
Marijn[m] has quit [charon.oftc.net coulomb.oftc.net]
vknecht[m] has quit [charon.oftc.net coulomb.oftc.net]
z3ntu has quit [charon.oftc.net coulomb.oftc.net]
prawn has quit [charon.oftc.net coulomb.oftc.net]
mort_ has quit [charon.oftc.net coulomb.oftc.net]
prawn has joined #linux-msm
z3ntu has joined #linux-msm
MartinBotka[m] has joined #linux-msm
x[m]1 has joined #linux-msm
Marijn[m] has joined #linux-msm
vknecht[m] has joined #linux-msm
x[m]1 has quit [Max SendQ exceeded]
x[m]1 has joined #linux-msm
jn has quit []
jn has joined #linux-msm
<anholt>
minecrell: apparently the dev had dropped the OTG workaround patch due to a bunch of dts moving, then later realized it was still needed.
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
pevik_ has joined #linux-msm
gpiccoli_ is now known as gpiccoli
BobBeck8 has quit []
BobBeck has joined #linux-msm
flowriser has quit [Remote host closed the connection]
flowriser has joined #linux-msm
Rayyan has quit [Remote host closed the connection]
Rayyan has joined #linux-msm
Rayyan is now known as Guest952
minecrell0 has quit []
minecrell has joined #linux-msm
<flto>
lumag, vkoul: btw, some issues I found with your sm8450 patches: spmi v7 is broken (pmic_arb_offset_v7 is wrong for writes, pmic_arb_irq_clear_v7/pmic_arb_irq_clear_v5 are reversed), usb doesn't work without turning on GCC_USB3_0_CLKREF_EN, apps_smmu interrupts are wrong (should be #global-interrupts = <1>;, also missing an interrupt)
<Mis012[m]>
flto: since you are around, any suggestion for how to model the SSCAON registers?
<flto>
Mis012[m]: power domain maybe? no idea what is SSCAON
<Mis012[m]>
flto: it's in the PSHOLD module
<Mis012[m]>
and all I know is that I need to set some bits in MPM_SSCAON_CONFIG0 and MPM_SSCAON_CONFIG1
<Mis012[m]>
and I'm not sure how to pass the addresses to the driver
<Mis012[m]>
currently I hardcode two ioremap calls
<Mis012[m]>
flto: there is a driver which claims the `MPM_PS_HOLD` register
<flto>
Mis012[m]: just pass the addresses like normal? pshold driver only uses the first register
<Mis012[m]>
should I put them in `reg`?
<Mis012[m]>
it feels a bit weird to go from no `reg` to `reg` having these two random registers which I need to access
<Mis012[m]>
since in most cases `reg` nicely encompasses a whole IP block
pevik_ has quit [Ping timeout: 480 seconds]
<lumag_>
flto, thanks
<vknecht[m]>
any tip what to check first when fastboot'ing a specific boot.img, the (msm8939) device goes to 9006 / QHSUSB__BULK mode ? my guess (with some leads from experimenting) is kernel config... thoughts ?
flto_ has joined #linux-msm
<vknecht[m]>
using gcc-linaro-12.0.0-2021.10-x86_64_aarch64-linux-gnu to build kernel, could that be a problem ?
<vknecht[m]>
(5.15)
flto has quit [Ping timeout: 480 seconds]
flto_ has quit []
flto has joined #linux-msm
<Mis012[m]>
why would you not just use the distro's gcc?
<vknecht[m]>
I don't think it is, and Fedora has not failed for the years I've used it. Maybe that point is a shortcoming, but then back to my question, could the Linaro prebuilt be a problem ? :-)
<Mis012[m]>
unlikely...
<vknecht[m]>
ok, that seems to comfort my guess about kernel config, because building with the same config with pmOS envkernel led to the same 9006/QHSUB_BULK problem
<vknecht[m]>
I just wish I knew clear criters for qcom soc/system to switch to that mode, that could help since I don't have uart
<Mis012[m]>
if you have a firehose, you can try peeking at ramoops
<vknecht[m]>
hmm, I do... how would I do that, concretely ?