<narmstrong>
Marijn[m]: I investigated and my current conclusion is:
<narmstrong>
- the panel doesn't autorefresh, so we need to update at each refresh, so far I didn't found how to enable autorefresh
<narmstrong>
- we disable autorefresh on the DPU, but without autorefresh fbcon won't work, but seems we don't enable HW autorfresh nor SW autorefresh
<narmstrong>
- the TE events are not received, this may explain why display is garbled because we don't sync on the TE event correctly
<narmstrong>
there's a kthread that seems totally unused: vsync_event_work, it's never started
<narmstrong>
same for vsync_event_timer, it does nothing
<Marijn[m]>
narmstrong: DPU autorefresh should be off of course, as we're submitting frames as we go
<Marijn[m]>
narmstrong: I'm not fully confident on the terminology but I think it's panel self-refresh where the panel keeps displaying the last picture sent to it stored in internal memory, instead of going to black after displaying, which is what you seemed to be suggesting
<narmstrong>
Marijn[m]: except in legacy fbcon mode where we don't know when fb buffer is damaged
<narmstrong>
Marijn[m]: yep sorry self-refresh
<Marijn[m]>
narmstrong: Now you're saying the panel is garbled... If you run modetest do you see SMPTE at least, but with tearing?
<Marijn[m]>
I'm surprised the signal never arrives, did you remove disp-te from DTS?
<narmstrong>
Marijn[m]: yep but there's clearly badly synchronized
<narmstrong>
Marijn[m]: I checked and I never had disp-te-gpios so the pinctrl mode is correctly configured
<Marijn[m]>
But if you have a pinctrl with mdp_vsync in the panel it should be good?
<narmstrong>
yep it should be good
<Marijn[m]>
I guess you need a board/hardware manual at this point to understand what makes the HW read the pin... From a DPU perspective the source is always set to GPIO
<Marijn[m]>
Maybe the bias is incorrect? Doesn't explain why you saw 144Hz in gpiomon though
<narmstrong>
Perhaps there's a register to select which gpio to use, because AFAIK there's 4 of them, but so far all the register setting the TE source are the same
<Marijn[m]>
What does your downstream say for the GPIO vsync source? Mine always says 0...
<narmstrong>
qcom,mdss-dsi-te-pin-select is 1, but AFAIK in source this is used as 0
<narmstrong>
1 means `DSI_TE_ON_EXT_PIN`
<narmstrong>
qcom,panel-te-source = <0x00>; which is used as-is for vsync_source
<Marijn[m]>
`qcom,panel-te-source = <0>;` is what I was looking for
<Marijn[m]>
That's the pin index, iirc
<Marijn[m]>
Which gets written as-is to a register in the hardware, but that should be all good then
<minecrell>
bryanodonoghue: the _a variant does not appear in the schematics. The RPM allows voting for each resource as either "active-only", "sleep-only" or both. Where sleep usually refers to the deepest idle state of the CPU cores
<minecrell>
You need the _a/"active-only" variant when voting for resources needed by the CPU cores
<minecrell>
e.g. the CPU cores need XO permanently as "active-only" because it always needs to be enabled when the CPU cores are running
<aka_[m]>
do we switch cpu to XO or it does it automaticaly/
<minecrell>
aka_[m]: all clocks are derived from xo
<aka_[m]>
i mean by default XO is input 0
<aka_[m]>
and we switch between 4 and 5 (gpll0,dedicated) so when we want to put cpu to sleep will it be put to 0(xo)?
<minecrell>
aka_[m]: no, there is no need to switch the CPU to use xo
<bryanodonoghue>
minecrell my understanding of CXO is that is is buffered via the PMIC
<bryanodonoghue>
the RPM "waggles the line"
<bryanodonoghue>
and I can see a CXO input on the schematic
<bryanodonoghue>
where would the _A_ version of CXO come from ?
<minecrell>
There is no _A_ version of CXO
<bryanodonoghue>
yeah
<minecrell>
This is purely a software construct
<bryanodonoghue>
but does RPM understand what I mean ?
<bryanodonoghue>
If I vote for RPM_SMD_XO_A_CLK_SRC
<bryanodonoghue>
instead of RPM_SMD_XO_CLK_SRC
<bryanodonoghue>
maybe I'm not making sense
<bryanodonoghue>
ah the macro creates both
<bryanodonoghue>
so the _A_ should make sense for the APSS
<narmstrong>
Marijn[m]: ok INTF definitely gets the TE signal, at correct rate, the INTF_TEAR_INT_COUNT_VAL reg gives the TE count, and it grows at ~144Hz per second
rawoul has joined #linux-msm
<narmstrong>
I managed to enable autorefresh, and it's clearly badly synchronized
rawoul has quit []
rawoul has joined #linux-msm
<narmstrong>
but INTF_FRAME_COUNT gives 74Hz
<narmstrong>
so I think I have an issue with DSI, the rate & timings must be bad
<narmstrong>
Marijn[m]: looking downstream code and the pclk/bitclk/byteclk is not obvious in cmd mode