<lumag_>
Marijn[m], I was OOO for the last week, just email access.
<lumag_>
I'll probably start looking onto the rest of the patches now.
<Marijn[m]>
lumag_: Thanks! Thought I saw lots of activity over the past week
<lumag_>
Marijn[m], yep, but no patches, no tree updates.
<Marijn[m]>
lumag_: That explains :)
<lumag_>
Sorry for not being explicit about that.
<Marijn[m]>
lumag_: How's your sdm660 board on 5.19 rc's? I had to revert all of drm/msm to 5.18 for it to continue, but haven't had time to dig in yet. Did you see anything similar?
<lumag_>
Marijn[m], let me try with linux-next
<Marijn[m]>
lumag_: I haven't checked -next yet, perhaps it has already been fixed though. If it has we should probably find what it was and make sure it makes it into 5.19?
<Marijn[m]>
I've only checked rc4 though, not rc5 yet
<Marijn[m]>
lumag_: Just in case my UART only gave me a possible hint/cause once: `dsi_cmds2buf_tx: cmd dma tx failed, type=0x15, data0=0x35, len=4, ret=-110`
* lumag_
is building -rc5
<Marijn[m]>
lumag_: Checked rc5, same problem
<lumag_>
So, rc1 did work, rc5 does not
<lumag_>
?
<Marijn[m]>
I only checked rc4 and rc5
<lumag_>
My ifc6560 support was based on rc1
<Marijn[m]>
Last time I tested, where it works, was 5.18 stable
<Marijn[m]>
Rebased on rc1, let's build and see
<Marijn[m]>
Seems to have gotten stuck as well :/
<Marijn[m]>
And reboots
<Marijn[m]>
lumag_: It'd be funny if this is caused by my DSI clock patches, wouldn't it?
<lumag_>
well might be :D
* lumag_
is building rc1
<Marijn[m]>
lumag_: Doesn't seem to be the case, issue persists after dropping them
<lumag_>
Marijn[m], Hmm.
<lumag_>
rc5 reboots
<lumag_>
rc1 doesn't reboot, but there is a display issue
<lumag_>
so, we have two different issues
<Marijn[m]>
lumag_: How quickly? For me it's when userspace tries to start and immediately acquire the panel... It sits there for a while with nothing on UART instantly, then reboots
<lumag_>
I don't have a panel here, it's a bridge
<Marijn[m]>
lumag_: Saying maybe my device might start booting if I remove the panel/dsi from it
<lumag_>
Marijn[m], Hmmm. Now I completely don't get it. For me even 5.18 results in black screen. I don't think I had a tag with which I tested mdp5 config.
Daanct12 has joined #linux-msm
Danct12 has quit [Read error: Connection reset by peer]
<jstultz>
bamse: looking at what else calls enable_irq() around there the qcom_lmh_dcvs_notify() code looks a little suspicious. From a skim, it seems like one could still get to the enable_irq() call w/ throttled_freq being uninitialized.
<bamse>
jstultz: i thought we got the ordering of those things in order...
<bamse>
detected a few different races there a little while back
<aka_[m]>
Do dpu somehow depend on adreno?
<aka_[m]>
On mdp5 I was able to have panel bound and use llvmpipe
<bamse>
aka_[m]: i'm running dpu without gpu on my sc8280xp...
<bamse>
aka_[m]: but if you have a present, but broken gpu, things don't go so well
jhovold has quit [Ping timeout: 480 seconds]
<aka_[m]>
bamse: I probably do something wrong but once I stopped seeing errors about dpu/dsi_phy I'm unable to even see if it's working, all I see is just one msg about adding mdss to iommu. Back in time when it was crashing I seen some logs like dpuhw version and about switching to dpu
<aka_[m]>
I seen commit in next for 8996 with adding mdp clock to mdss to be able to see some data and i will try that as I dropped it from mdss node where I had it before with assigned rate
<konradybcio>
if you don't see the hw revision, it's likely not probing
<konradybcio>
it may be waiting for some dependency
<aka_[m]>
Devices deferred is empty
<konradybcio>
check if it's enabled
<aka_[m]>
I seen only some phy info about fixing cycling dependency
<konradybcio>
oh hm
<aka_[m]>
konradybcio: I haven't disabled anything meanwhile so shouldn't happen
<konradybcio>
are you on 5.18 or 19?
<aka_[m]>
19 rc2 or so
<aka_[m]>
16.06
<konradybcio>
don't know about rc2, i surely have dpu working on rc3
pespin has quit [Remote host closed the connection]
<lumag_>
bamse, sboyd, can I ask your opinion? clk_alpha_pll_configure(). The code adds alpha_en_mask and alpha_mode_mask to val (but not to mask). So these bits are going to be ignored.
<lumag_>
Should we continue ignoring them (and thus drop the code) or should we add them to the mask instead?
<konradybcio>
i wonder if that's the reason my pll refuses to work..
<lumag_>
konradybcio, good question :-)
<lumag_>
I was actually thinking whether we should drop pll_config/alpha_pll_config completely and use statis values instead
<sboyd>
lumag_: I dont expect to enable the pll on configure
<lumag_>
sboyd, but then the alpha_en_mask is completely unused
<bamse>
lumag_: as written that doesn't make sense to me...
<bamse>
sboyd's input seems more reasonable, in which case we should probably mask but not val
<lumag_>
yep
<bamse>
but in its current form, i think it's possible that we're modifying a running pll...
<bamse>
if we start clearing the en bits we might turn it off
<lumag_>
I think we can just drop these two lines (and corresponding config entries)
<lumag_>
generic question: wdyt about turning all these calculations into config_user_ctl_val & config_user_ctl_mask?