<Danct12>
do i need the TE pin if qcom,mdss-dsi-te-using-te-pin is commented out on downstream?
junari has joined #linux-msm
<Marijn[m]>
Danct12: you almost never want the TE pin as `disp-te-gpio(s)` in your DT. That causes `mdp_host` to change the function and make the hardware unable to receive interrupts (breaking vsync). Instead, you want to have pinctrl on that node to select `func = "mdp_vsync"`.
<Danct12>
Marijn[m], thanks! that isn't what i was asking for
<Danct12>
i was asking if i should use the TE pin if downstream has it commented out
junari has quit [Remote host closed the connection]
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #linux-msm
<aka_[m]>
no
<aka_[m]>
there is reason its commented
<aka_[m]>
best if you can grab schematics
<aka_[m]>
or from dowstream you can try reading gpio state from register
<aka_[m]>
i believe these can be easily readed if you point at proper reg
<aka_[m]>
also ds debug of pinctrl has states of gpios
<Marijn[m]>
Danct12: downstream is useless here because it doesn't use that DT property (as I said, if it did, and registered it as GPIOD_INPUT, hardware vsync in the host would break)...
<Marijn[m]>
s/host/mdp
<Marijn[m]>
Instead, check for example if the poweron commands send tear_on.
<Danct12>
Marijn[m], doesn't seem to send {0x35, 0x00}
<Marijn[m]>
Then maybe it is not using it. What does it set vsync-source to?
<Marijn[m]>
Danct12: just to check, does it maybe send `0x34` to turn TE _off_ on the panel, or nothing at all? (0x35, 0x00 would turn on tear on vblanks, 0x35, 0x01, would turn on tear on vertical _and horizontal_ blanks)
<Danct12>
i cant even find anything about 34 :P
<Danct12>
i also cant find vsync-source, maybe this was on newer devices? this is a sm6115
<Danct12>
there's qcom,platform-en-gpio = <&tlmm 65 0>; which sets to low when reset
<Marijn[m]>
Probably a more important question is whether your panel, and by extension proper vsyncing at the expected refresh rate, is working?
<Danct12>
it fails to initialize, and it's the same panel as last year
<Marijn[m]>
Yeah 0xb0 is the first command that is sent, and this driver doesn't set prepare_prev_first... That is very likely the problem. I don't remember if there is - but if there isn't there should be - a log message explaining that the DSI host is off
<Danct12>
there's `qcom,mdss-dsi-lp11-init` in the display panel
<Marijn[m]>
Danct12: set `boe->panel.prepare_prev_first = true` **before** caling `drm_panel_add()`
<Marijn[m]>
That reminds me, I wonder if prepare_prev_first was solved for the disable/unprepare case as well... That should unblock me to send a whole bunch of Sony panels in a v2
adomerle has joined #linux-msm
<adomerle>
dual dsc fix eta
<Danct12>
there's also..
<Danct12>
panel-sw43404-boe-fhd-amoled 5e94000.dsi.0: Failed to set display off: -22
<Marijn[m]>
Danct12: sounds like that case... was not fixed then :(
<Danct12>
which calls the standard mipi dsi power off code
<Danct12>
s/code/function
<Marijn[m]>
i.e. the host controller is turned off before panel unprepare() is called, so that you can no longer send DSI commands
<Marijn[m]>
Though display_off should be sent from disable(), not unprepare() typically
<Marijn[m]>
adomerle: I still haven't heard about my devcoredump, and don't really want to submit incomplete patches
<Marijn[m]>
I could send the first batch though as a lot of folks seem to be depending on some sort of dual dsi / dual dsc architecture lately
<Marijn[m]>
But it also hinges on me and lumag figuring out a way to make progress on the shared Active-CTL series
<Danct12>
a fix for a 2 years old driver with no users
<Danct12>
until one came
<Danct12>
as for qcom,platform-en-gpio i assume a node in &tlmm will do?
<aka_[m]>
uh
<aka_[m]>
im not sure if you need fixes tag
<aka_[m]>
it wasn't broken
<aka_[m]>
"fixes" are meant to be also backported but it was somewhere during change of bridges or something
<aka_[m]>
well Marijn would know for sure if you should send with fixes tag
<Danct12>
i hate this phone firmware so much
<Danct12>
every time i hold down the power button (do a hard reset) it would drop itself into QUSB_BULK
<Danct12>
as a bonus it can even dump the whole memory content using edl.py
ungeskriptet has joined #linux-msm
<Marijn[m]>
<Danct12> "a fix for a 2 years old driver..." <- I don't think it's fixing anything when the semantic behaviour of dsi_bridge and friends was different back then
<Marijn[m]>
However, perhaps there was a patch that was supposed to reflect this behavioural change by at the very least fixing/updating all existing DSI drivers with that flag?
<aka_[m]>
probably
<aka_[m]>
any idea if current mesa fixes anything compared to one packaged now in alpine?
<aka_[m]>
on older gpus like a5xx which is very broken rn
flto has quit [Remote host closed the connection]
flto has joined #linux-msm
<Danct12>
anyway to get around flashbang mode when it comes to oled?