krishchow[m]1 has quit [Remote host closed the connection]
lumag__ has quit [Ping timeout: 480 seconds]
Thete has joined #linux-msm
Thete is now known as Guest2581
Guest2581 has quit [Remote host closed the connection]
<konradybcio>
i don't think it's been brought up here, but do you guys also have issues with 8250 dpu?
<konradybcio>
i suspect cont_splash might be working against us once again, but mdss clocks are going crazy and the usual ways of solving these things (or even going as far as forwardporting downstream clock thingies) doesn't solve the issue at all
NikolayN-t has joined #linux-msm
NikolayN-t has quit [Remote host closed the connection]
alex19EP23 has joined #linux-msm
alex19EP23 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-18 02:11:27)]
hexdump01 has joined #linux-msm
hexdump0815 has quit [Ping timeout: 480 seconds]
Nordin6 has joined #linux-msm
Nordin6 has quit [Remote host closed the connection]
anholt has quit [Remote host closed the connection]
anholt has joined #linux-msm
YarikKiller-t has joined #linux-msm
YarikKiller-t has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-18 05:29:51)]
cmeerw has joined #linux-msm
cmeerw has quit [Ping timeout: 480 seconds]
xavoc3 has joined #linux-msm
xavoc3 has quit [Remote host closed the connection]
flyback18 has joined #linux-msm
flyback18 has quit [Remote host closed the connection]
<ndec>
konradybcio: check with lumag ..
motte29 has joined #linux-msm
motte29 has quit [Remote host closed the connection]
k_rad has joined #linux-msm
k_rad has quit [Remote host closed the connection]
DavePifke[m] has joined #linux-msm
DavePifke[m] has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-18 07:08:16)]
sebl has joined #linux-msm
sebl has quit [Remote host closed the connection]
<lumag>
konradybcio: what kind of issues do you face?
svarbanov has joined #linux-msm
Alternity has joined #linux-msm
Alternity has quit [Remote host closed the connection]
incognito has joined #linux-msm
incognito is now known as Guest2616
Guest2616 has quit [Remote host closed the connection]
dalias20 has joined #linux-msm
dalias20 has quit [Remote host closed the connection]
shs3g32f has joined #linux-msm
shs3g32f has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-18 08:06:23)]
LiveWire has joined #linux-msm
LiveWire has quit [Remote host closed the connection]
marvin24 has joined #linux-msm
<konradybcio>
That's right, sorry for not explaining upfront, I fell asleep shortly after sending that message..
alperbek[m|gr] has joined #linux-msm
alperbek[m|gr] has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2021-06-18 10:46:25)]
shiznix has joined #linux-msm
shiznix has quit [Remote host closed the connection]
lumag__ has joined #linux-msm
midgard has joined #linux-msm
midgard is now known as Guest2637
Guest2637 has quit [Remote host closed the connection]
csws has joined #linux-msm
csws has quit [Remote host closed the connection]
vedranm has joined #linux-msm
vedranm has quit [Remote host closed the connection]
Spritz has joined #linux-msm
Spritz has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-18 12:16:06)]
GreatGodvin has joined #linux-msm
GreatGodvin has quit [Quit: WeeChat 3.2]
GreatGodvin has joined #linux-msm
GreatGodvin has quit [Quit: WeeChat 3.2]
GreatGodvin has joined #linux-msm
cmeerw has joined #linux-msm
GreatGodvin has quit [Quit: WeeChat 3.2]
GreatGodvin has joined #linux-msm
CMoH|notebook has joined #linux-msm
CMoH|notebook has quit [Remote host closed the connection]
GreatGodvin has quit [Quit: WeeChat 3.2]
GreatGodvin has joined #linux-msm
GnuLxUsr has joined #linux-msm
GnuLxUsr has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-18 15:36:07)]
cris has joined #linux-msm
cris has quit [Remote host closed the connection]
Guest2660 has joined #linux-msm
Guest2660 has quit [Remote host closed the connection]
GreatGodvin[m] has joined #linux-msm
GreatGod1 has joined #linux-msm
GreatGodvin has quit [Ping timeout: 480 seconds]
GreatGod1 has quit []
GreatGodvin[m] has quit [Ping timeout: 480 seconds]
devalnor[m]3 has joined #linux-msm
devalnor[m]3 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-18 16:44:18)]
walzu1 has joined #linux-msm
walzu1 has quit [Remote host closed the connection]
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
ris has joined #linux-msm
ris has quit [Remote host closed the connection]
fnords has joined #linux-msm
fnords has quit [Remote host closed the connection]
MapMan has joined #linux-msm
MapMan has quit [Remote host closed the connection]
ishanjain28 has joined #linux-msm
ishanjain28 has quit [Remote host closed the connection]
computerkiller has joined #linux-msm
computerkiller has quit [Remote host closed the connection]
<minecrell>
bamse: Um, so for some reason the net people already applied my RPMSG WWAN CTRL driver series without an ack even for that simple "rpmsg: core:" patch at the beginning...
<minecrell>
bamse: Not sure if this is expected?
<minecrell>
I kind of expected having to wait for an ack from someone :D
cmeerw has quit [Ping timeout: 480 seconds]
<bamse>
minecrell: well...they seem to be in a very good mood this week
phaazon9 has joined #linux-msm
phaazon9 has quit [Remote host closed the connection]
<minecrell>
bamse: I mean, *I* don't mind of course, I just don't want this to explode in a few weeks :)
<bamse>
right
w0rm has joined #linux-msm
w0rm has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-18 21:09:31)]
<Mis012[m]>
bamse: any idea on debugging the reboot?
<Mis012[m]>
or if not using _v2 could cause that
<bamse>
Mis012[m]: i'm afraid not...it's just a black box to me as well :/
<Mis012[m]>
bamse: you are one of the few people outside qcom with actual use for their real deal docs :(
<Mis012[m]>
well, I could count myself, but that's hardly an official relationship :P
<Mis012[m]>
bamse: guess why I wanted to just do everything from Linux...
<Mis012[m]>
one less black box to babysit
RaaFaTKhaLeD-t has joined #linux-msm
RaaFaTKhaLeD-t has quit [Remote host closed the connection]
<bamse>
well, i might have some documentation, but i don't even know where to start looking for something like this...or if it even would be documented
KonstantinG3-t has joined #linux-msm
KonstantinG3-t has quit [Remote host closed the connection]
<konradybcio>
So you're saying that qcom is so messy that you need docs for their docs? Hehe
<Mis012[m]>
I would probably try pdfgrep
<Mis012[m]>
the init sequence should be documented in real deal docs
<Mis012[m]>
but that's not the current issue
<Mis012[m]>
the current issue is working around qcom's design decisions because they scare the shit out of anyone who would want to modify the sw stack
<bamse>
konradybcio: i'm saying that there's a lot of things to document...
<bamse>
konradybcio: and hence a lot of documentation
<konradybcio>
well true that, MSMs are extremely complex pieces of hw
<Mis012[m]>
and even if it's still possible to control TZ code with a secure-boot-on device, I bet it's highly discouraged...
<bamse>
and afaict Mis012[m] has the particular sequence figured out, but something goes wrong somewhere
<Mis012[m]>
bamse: well, I have the init sequence worked out completely for the SSC block
<Mis012[m]>
but you say that people are unwilling to do that from Linux
<Mis012[m]>
since that would mean modifying TZ and HYP to allow for those ranges to be assigned to Linux
<Mis012[m]>
bamse: if qcom's BSP at least wasn't broken...
<bamse>
Mis012[m]: no that's no the reason i gave you
<Mis012[m]>
well, most phone OEMs won't do anything at all that would help us
<Mis012[m]>
so not convinced it matter if we try to make it less work for them
<Mis012[m]>
bamse: well, they don't want to modify TZ and HYP because that would mean losing all of qcom's guarantees?
<Mis012[m]>
which I care for as much as I care for the sw itself, but we don't have a full-stack replacement anyway
<Mis012[m]>
loading a dummy fw could be a smart way to initialize the bus without TZ and HYP changes
<Mis012[m]>
but then it would have to not fail without telling me why :/
<konradybcio>
adreno would not work without secret tz sauce
<konradybcio>
that's a pretty big deal if you ask me :P
<konradybcio>
and well, DVFS on newer socs
<Mis012[m]>
well, that's not even the issue here
<Mis012[m]>
it's just that devcfg currently doesn't allow reassigning the registers needed to bring that clock up
<Mis012[m]>
so if one has TZ and HYP sources and adds that as things you can define in devcfg, you can happily keep secure boot on
<konradybcio>
bamse does mdss work on the RB5? and if so, does it have cont_splash?
<Mis012[m]>
but the issue is that if you you change TZ and HYP, you
<Mis012[m]>
1) loose any of qcom's gurantees that their sw doesn't suck too badly
<Mis012[m]>
and 2.) probably will have to use a completely different boot scheme so you can avoid having to get your stuff signed by qcom
<konradybcio>
we're still investigating stuck mdss_ahb_clk/mdss_mdp_src_clk and mmcx on edo and I'm starting to wonder if there's a wider issue :/
<Mis012[m]>
it it stuck ON? :P
<Mis012[m]>
that's a completely different issue than I had xD
<Mis012[m]>
I would almost not even complain about that :P
<Mis012[m]>
can't you just pull the BCR?
<konradybcio>
i have to dig up a dmesg, this gave me so much headache I don't even remember at this point
<konradybcio>
disp_cc_mdss_mdp_clk_src rcg didn't update its conf
<konradybcio>
disp_cc_mdss_ahb_clk stuck at off (or "already disabled", fun stuff)
<Mis012[m]>
oh, stuck at off
<Mis012[m]>
that's not nice
<konradybcio>
my theory is that dpu shuts down the clocks in the wrong order
<Mis012[m]>
hmm
<Mis012[m]>
makes sense I guess
<konradybcio>
essentially, some clocks depend on others being on and dpu cuts off some base level of the tree and the SoC doesn't catch that the lower ones should be disabled too
<konradybcio>
and they are on because cont_splash
<Mis012[m]>
yeah, it shuts down a prerequisite, so it goes down by itself
<Mis012[m]>
and then it tries to disable it and it's "already disabled"
<Mis012[m]>
turning them back on in the wrong order could be an issue as well I guess, since Linux checks if it worked
<Mis012[m]>
you could put HALT_SKIP to see if not checking immediately solves it
<Mis012[m]>
basically "don't bother checking, just assume it worked"
<Mis012[m]>
it should still get saved should the prerequisites come online methinks
marvin24 has joined #linux-msm
ShawnMcCool has joined #linux-msm
ShawnMcCool has quit [Remote host closed the connection]
marvin24_ has quit [Ping timeout: 480 seconds]
ThothCastel has joined #linux-msm
ThothCastel has quit [Remote host closed the connection]
<bamse>
konradybcio: yes, the display on rb5 works...and i _think_ the bootloader renders something on the screen, but not sure
<bamse>
konradybcio: but regarding the mdp clocks...perhaps this you're seeing an issue similar to what i've been poking on 845...
<bamse>
konradybcio: iirc the mdp_clk doesn't have a is_enabled, because it's hardware controlled, so without clk_ignore_unused we're disabling the _src clk without first gating the mdp_clk and then as we're trying to turn things on again the hardware is stuck
<bamse>
disp_cc_mdss_ahb_clk status stuck at 'off'
<konradybcio>
yep, same here
<konradybcio>
ok so now the device dies with your gdsc patch
<bamse>
just wish i wrote down my notes on this...
<konradybcio>
I guess that means it's getting further, let's try clk_ignore_unused
<bamse>
perhaps because you're actually turning off the power to something now? ;)
<konradybcio>
:)
<bamse>
my notes does say that booting with clk_ignore_unused works around the problem...because we don't lock up the clock
<bamse>
but as you say, is_enabled is implemented for the branch, so it must be some related clock
<konradybcio>
hm clk_ignore_unused does not help
<konradybcio>
that's worrying
<konradybcio>
let's also try pd_ignore_unused..
<bamse>
right, 845 doesn't have the separate mmcx, so that reduces the problem space
<bamse>
okay, so the problem must be that the clk lateinit skips disp_cc_mdss_mdp_clk_src and turns of its parent
<bamse>
because that's the shared rcg involved
<konradybcio>
but why does it turn off the parent if it's a known-parent-of-a-used-clock so.. it's not unused
<bamse>
clk_src doesn't implement is_enabled and is assumed to be off
<bamse>
and as mdp_clk_src is shared ownership with the display rsc we can't implement is_enabled, because it might change "randomly" and that would confuse the clock code
<Mis012[m]>
can't that be modelled?
<Mis012[m]>
as long as both are controlled by Linux
<bamse>
sboyd: konradybcio is hitting the issue i was investigating a while ago (but shelved)...where we don't know if mdp_clk_src is enabled so we just skip disabling that in the late initcall and then lock up the hardware by turning off the parent clock
<bamse>
sboyd: do you have any suggestion to how we should model this? perhaps another quirk saying that lateinit can assume it's on?
<bamse>
Mis012[m]: linux and the display hardware both controls that clock
<bamse>
Mis012[m]: so is_enabled() might return true because the display hardware has it enabled, skip enabling because it's already on and then it's turned off under our feet
<Mis012[m]>
bamse: so there should be hw voting but qcom did an oopsie?
<bamse>
Mis012[m]: i think it's a software issue
bam has joined #linux-msm
bam has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-18 23:21:43)]
<bamse>
konradybcio: but i don't know why this would work with boot splash enabled...seems backwards
<konradybcio>
except it doesn't here
<konradybcio>
I cannot disable the cont_splash and it does not work
<bamse>
i see, on 845 things works if the bootloader has enabled the display...otherwise i run straight into that issue...but logically it should only be a problem if the bootloader left the clocks on
<konradybcio>
..unless your rb5 is so smart that it turns the display on and then turns it off before jumping to linux
<konradybcio>
oh 845
<bamse>
but you can check if it's the same problem by hacking up the clk lateinitcall and just pretend like is_enabled returned true for the mdp_clk_src...
<bamse>
then we know if it's the exact same issue
<Mis012[m]>
bamse: hmm, should Linux check bit 0 then?
<Mis012[m]>
instead of 31
<Mis012[m]>
"did I try to enable it"
<Mis012[m]>
vs "is it on"
<Mis012[m]>
and if bit 0 is on but bit 31 is off, then that means it's stuck off?
<bamse>
Mis012[m]: might actually be possible to do that, although that's not exposed in the api
<bamse>
Mis012[m]: no, the "stuck off" is a side effect of us removing the incoming clock without first stopping the rcg, so the hardware locks up
<bamse>
Mis012[m]: so the problem is that we don't disable the clock cleanly
<bamse>
Mis012[m]: so the only way to then later start is to send the reset signal to dispcc
<Mis012[m]>
normally stuck off means that Linux has set bit 0 but bit 31 wasn't cleared?
<Mis012[m]>
which should still hold
<bamse>
i think you're right...but at that point all you can do is observe that the hardware is in a bad place
<Mis012[m]>
yeah
<bamse>
it's too late to do anything sensible about it
<Mis012[m]>
could try resetting BCR
<Mis012[m]>
but then you're in a loop
<bamse>
i looked at that, but the reset for this bit covers a ton of stuff
<bamse>
and still, it's only locked up because linux didn't play nice in the first place
<bamse>
so we should be able to fix that
<Mis012[m]>
yeah it probably wasn't an accident anyway, so it will happen again
<Mis012[m]>
maybe add HALT_VOTE or something like that?
<Mis012[m]>
signalling that the HALT bit has a different meaning because we're effectively voting
<konradybcio>
bamse I hacked up all dispcc rcg2_shared clocks (disp_cc_mdss_ahb_clk_src, disp_cc_mdss_mdp_clk_src & disp_cc_mdss_rot_clk_src) to always report being enabled to no change
Vladimir-t has joined #linux-msm
Vladimir-t has quit [Remote host closed the connection]
<bamse>
konradybcio: hmm, then i need to refresh my memory on what the problem actually is :/