ChanServ changed the topic of #linux-msm to:
<Marijn[m]> Also, disable the reset gpio
<lumag> calebccff, post-on should be sent, it's display-on + enter-normal-mode
<Marijn[m]> If it's working in some bl splash mode, most likely one thing is not configured or configured incorrectly after the reset
<calebccff> im sending post-on
<calebccff> i'll try skipping reset
<lumag> calebccff, also note the HS mode switches
<lumag> So you might have to play with LPM
<lumag> And don't forget delays.
<calebccff> oh yeah i think im missing some mode switches
<calebccff> \o/ it works without reset
<lumag> Heh. Same hellish pit as the one we had for P3.
<calebccff> yeahhh
<lumag> Dump DSI transfers + types that are used downstream and match them upstream.
<calebccff> urgh that'll be fun
<calebccff> i also found a potential gpio-regulator and added that so just gonna check that it wasn't the real fix
<calebccff> bah, i would be so lucky :(
<lumag> calebccff, you might need to move post-on to panel's enable callback
<lumag> calebccff, Also... I have some bad news for you.
<lumag> I don't know if that makes a difference or not.
<calebccff> ohno
<calebccff> XD
<lumag> mipi_dsi_dcs_write_seq() uses MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15 for 2-byte writes.
<lumag> However in the DT you provided there are plenty (but not all) 2-byte writes that use 0x39
<lumag> aka MIPI_DSI_DCS_LONG_WRITE
<calebccff> ooh
<calebccff> surely... the panel firmware isn't that broken
<lumag> I wouldn't bet on that.
<lumag> It might be worth adding a function that dumps a buffer using 0x39 type and attempting to use it instead
<Marijn[m]> Good news about the reset trick!
<calebccff> lumag: good idea
<Marijn[m]> I should make doubly sure that I've tried that on a dual-dsc panel
<Marijn[m]> But after sleep, it's way past bedtime. Goodnight, looking forward to good panel news tomorrow!
<calebccff> gnight Xd
<lumag> gn!
<calebccff> lumag: you might find this interesting, dumped the panel config from XBL https://p.calebs.dev/fac3ed@raw
<lumag> Note, it also uses 39 for 2-byte
<calebccff> hmmm
<calebccff> so weird
<lumag> And it also has a pretty short sequence
<calebccff> lumag: it's weird that it's commented as being 24-bit
<lumag> calebccff, your dtsi also has qcom,mdss-dsi-bpp = <24>;
<calebccff> oh, hmm
<calebccff> simplefb is for sure 32bpp though
<lumag> 32 bpp = xrgb?
<lumag> 8-bit r+g+b.
<lumag> and 8 bits of padding
<lumag> so the panel itself is 24bpp
<calebccff> ahh ofc, makes sense
<calebccff> lumag: converted all the long writes to long writes, and progress! panel is now just a mess of color
<calebccff> it doesn't seem to update at all
<calebccff> brightness works though
<lumag> рур
<lumag> heh
<lumag> is that with the dtsi sequence or with the one from XBL?
<calebccff> dtsi sequence
<calebccff> lumag: i get "enc31 intf1 ctl start interrupt wait failed" and "wait for commit done returned -22"
<calebccff> when panel wakes up
<lumag> there might be a mess with the IRQs
<calebccff> but it was working without the reset? actually didn't check dmesg then though
<lumag> calebccff, XBL doesn't have the 'TSP Setting' part. Also note the difference, last command is SET_DISPLAY_ON
<calebccff> interesting
<lumag> 05 / 29, no 15 / 53 20
<lumag> the delay after exit_sleep_mode is too long
<calebccff> 0b is it not 11ms?
<lumag> ah, true
<lumag> it's usleep_range, not msleep
<lumag> 0x437 = 1080 - 1
<lumag> 0x95f = 2400 - 1
<lumag> It might be worth trying the sequence from XBL, it's slightly simpler.
<calebccff> lumag: probably a good idea, i'll remove the least important looking stuff first
<lumag> TSP & the tail looks promising
<calebccff> lumag: starting to think it's something deeper... hit some fun WARNs in the dpu https://p.calebs.dev/d94ca6@raw
<calebccff> lumag: if i skip the reset sequence then I don't hit them, everything works
<lumag> the warning means that there is already a callback registered for the IRQ
<lumag> any previous errors?
<calebccff> lumag: here's full dmesg https://p.calebs.dev/2e3796@raw
<calebccff> the stuff around "Failed to un-initialize panel: -22" is where I turned the panel off and back on, turning it on is what caused the WARNs
<lumag> [ 252.010795] panel-samsung-amb655x ae94000.dsi.0: sending command 0x9f failed: -22
<calebccff> that's the off command yeah
<calebccff> with reset disabled that still fails
<calebccff> but doesn't cause problems
<calebccff> oh i get the same "enc31 intf1 ctl start interrupt wait failed" errors too with the reset disabled
<lumag> so for some reason the driver skips unregistration of callbacks.
<calebccff> ahh
<calebccff> so also with the reset disabled this thing is running at like 2-3fps
<calebccff> with the "wait for commit done" errors on every frame
<calebccff> im getting deja-vu
<calebccff> ah well, too late for my brain to be focusing on this anymore
<calebccff> pushed what i've got, now time for zzzz
<calebccff> ooh, i tried re-enabling the TSP setting and the tail and now it's smooth with reset off \o/
<strongtz[m]> <konradybcio> "strongtz is that stored in..." <- konradybcio: uh no, not really, it needs to be decoded with some qc tools
<strongtz[m]> qcom couldn't be so nice regarding such *secure* stuff lol
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
junari_ has joined #linux-msm
Ojus1_ has joined #linux-msm
Ojus1_ has quit [Remote host closed the connection]
jhovold has quit [Quit: WeeChat 4.1.2]
junari_ has quit [Ping timeout: 480 seconds]
<aka_[m]> konradybcio: need some mental help with adrenos
<aka_[m]> why all schemas are written with size-cells/address-cells set to 1?
Caterpillar has quit [Quit: Konversation terminated!]
<aka_[m]> also is there way to make list of items then later for specific compatible cut like last one from list?