ChanServ changed the topic of #linux-msm to:
lumag_ has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
qyousef has joined #linux-msm
qyousef_ has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
enok has quit [Read error: Connection reset by peer]
enok has joined #linux-msm
Rayyan has quit [Read error: Connection reset by peer]
Rayyan has joined #linux-msm
jhovold has joined #linux-msm
pevik has joined #linux-msm
lumag_ has joined #linux-msm
dliviu has quit []
Daanct12 has quit [Quit: Leaving]
pespin has joined #linux-msm
dliviu has joined #linux-msm
gpiccoli has quit [Quit: Bears...Beets...Battlestar Galactica]
gpiccoli has joined #linux-msm
<calebccff> elder_: I had a small Question about IPA which I wasn't able to find much about online. Do you know if the IPA hardware is able to maintain a network connection (e.g to a notification push service) while the AP is suepended?
<elder_> Yes and no
<Mis012[m]> wouldn't be surprised if it could...
<Mis012[m]> worst case you can probably manage it from some other cpu
<elder_> Yes the hardware is able to do it. To my knowledge, it isn't working currently (I think it depends on modem firmware)
<calebccff> I've been looking into Android Doze and how they handle receiving notifications while the also making use of suspend, they tout their firebase messaging service but I couldn't find details on how they make that work
<elder_> I have code in place to handle it. But I could never reproduce the scenario, and I know the code doesn't work the right way...
<calebccff> Hmm I see, thanks
<elder_> So at some point, if I find a way to reproduce the behavior, I will make sure it works. It's designed to support that.
<elder_> Just to be clear, we're talking about something coming in from the internet, via the modem, which would wake up the AP, right?
<calebccff> yeah exactly that
<elder_> OK, then my explanation is what you asked for
<calebccff> thanks a lot :)
<elder_> You're very welcome.
<Mis012[m]> could probably have quite complex logic for whether to wake the AP, but that's all signed isn't it...
<calebccff> I'm quite interested in bringing over some Android doze features like "significant motion" based wakeup, and of course waking up for notifications is a big one
<calebccff> from what I understand currently mainline doesn't support having the modem wake the AP
<Mis012[m]> I think there was something about waking up for calls on 8916
<calebccff> yeah, the same IRQ is potentially used for other notifications though so we weren't sure if it's entirely correct
<Mis012[m]> makes sense, just need one
<Mis012[m]> maybe two so one can be non-wakeup
pespin has quit []
lumag_ has quit [Remote host closed the connection]
pevik has quit [Ping timeout: 480 seconds]
lumag_ has joined #linux-msm
lumag_ has quit [Remote host closed the connection]
Guest2435 has joined #linux-msm
Guest2435 has quit [Remote host closed the connection]
lumag__ has joined #linux-msm
pevik has joined #linux-msm
<Mis012[m]> ok, so I've successfully replaced the UEFI part of XBL with u-boot...
<Mis012[m]> but Linux booted this way seems to crash :/
<Mis012[m]> after this it goes right back to XBLLoader log and then u-boot log
<Mis012[m]> and then this again
<Mis012[m]> with u-boot in boot.img, it can boot Linux in the same way with Linux getting all the way to userspace no problem
jhovold has quit [Ping timeout: 480 seconds]
<konradybcio> what's the behaviour with maxcpus=4 and maxcpus=1?
<Mis012[m]> can try that tomorrow, but I would be surprised if it decides to not reboot
<Mis012[m]> what does eewefi do with the cpus anyway...
<Mis012[m]> I mean, it could be setting up a spin table, but we know damn well it's not
<konradybcio> ..or it could be applying some erratas..
<konradybcio> and/or setting up power rails
<konradybcio> perhaps some chicken bits?
<Mis012[m]> isn't applying erratas Linux's job?
<konradybcio> erm
<konradybcio> one word
<konradybcio> qualcomm
<Mis012[m]> or would that only be for actual CPU cores
<konradybcio> there are different kinds of erratas
<Mis012[m]> well... I guess
<konradybcio> some may be code flow / codegen changes, others may just be enabling/disabling chip features
<konradybcio> or altering the configuration of something
<Mis012[m]> so should grep for "errata" you say?
<konradybcio> i'm not saying that :P
<konradybcio> ultimately, since you have el2, you can get a small hwtracer hyp running and chainload xbl from your u-boot and see what happens
<Mis012[m]> but I can't fit u-boot in EL2 :P
<Mis012[m]> and writing a small hwtracer from scratch sounds like a lot of work
<konradybcio> or you can "just" chainload xbl from your hwtracer binary
<Mis012[m]> I mean, I can't fit it in HYP partition
<konradybcio> you can make m1n1 work on 8998
<konradybcio> you don't have armv8.2 so you'll have to knock off vhe
<Mis012[m]> the stuff that would be worth the effort can't really be traced like that though...
<Mis012[m]> ddr training for example
<konradybcio> i mean
<konradybcio> it can trace many kinds of things
<konradybcio> like stock blobs
<Mis012[m]> is there really something running in EL1 after HYP is loaded that I care to trace?
<Mis012[m]> I mean, a replay-based display driver wouldn't be too bad to have, but it would sure be ugly
<konradybcio> hm
<konradybcio> sde blobs would be nice to re
<konradybcio> there's a lot of them
<Mis012[m]> doesn't sound like something that runs in EL1 on a53
<konradybcio> they do
<konradybcio> grep for libsde
<konradybcio> color / gamma correction, hdr and stuff
<Mis012[m]> what's sde good for?
<konradybcio> also power saving algos
<Mis012[m]> > color / gamma correction, hdr and stuff
<Mis012[m]> doesn't sound like something to RE
<Mis012[m]> more like make from scratch
<Mis012[m]> nothing hw specific about that
<konradybcio> wrong
<konradybcio> they are per-device
<Mis012[m]> because downstream is stupid
<konradybcio> same for camera drivers and processing
<konradybcio> same for all things adreno
<Mis012[m]> camera drivers should clearly not be per device, how is that not obvious
<konradybcio> they are
<konradybcio> regulator settings
<Mis012[m]> because downstream is stupid
<Mis012[m]> > regulator settings
<Mis012[m]> goes in dts
<Mis012[m]> on mainline
<Mis012[m]> downstream is a dump, nothing to see there
<Mis012[m]> gamma correction is something for userspace to do using vendor agnostic v4l2 interfaces
<Mis012[m]> clearly
<konradybcio> qcom has tons of hardware for that, i think.. ..that you have to pass correct data to
<Mis012[m]> what downstream does is, in fact, not relevant
<Mis012[m]> > qcom has tons of hardware for that, i think.. ..that you have to pass correct data to
<Mis012[m]> yes, so you need a kernel driver which implements the v4l2 interfaces
<Mis012[m]> I mean, not sure about libcamera, but this seems common sense to me
<Mis012[m]> I had a lot of motivation to work on camera stuff as you can see :P
pevik has quit [Ping timeout: 480 seconds]