<narmstrong>
Marijn[m]: I tried recalculating the pclk like downstream, but it doesn't change anything.... I still have this weird 94Hz with modetest -v I don't honestly know where this comes from
<narmstrong>
seems something is limiting the MDP output frequency
<Marijn[m]>
narmstrong: but the counters you were reading back are still incrementing at an expected rate?
<Marijn[m]>
narmstrong: I don't recall the various things you tried with sync_cfg_height and what FPS you got... but during testing I always revert Angelo's patch (set it back to 0xfff0) to make sure vsync is purely driven by a panel interrupt
<narmstrong>
Marijn[m]: yes, the TE status increments at 144Hz
<narmstrong>
Marijn[m]: I have sync_cfg_height to 0xfff0 and it changes nothing
<lumag>
narmstrong, Marijn[m], unfortunately there is little I can help here, I have only video-mode panels or sinks
<Marijn[m]>
narmstrong: that is good, means the vsync is driven by the panel and not the MDP counter hardware "thingy"
<narmstrong>
lumag: it's non urgent but it would be cool to have a panel with the 4 modes supportes (vid, vid+dsc, cmd, cmd+dsc)
<Marijn[m]>
lumag: no worries, figuring it out is part of the fun :)
<lumag>
:-)
<narmstrong>
yep :-)
<Marijn[m]>
narmstrong: it's a regular work-day for me and I spent yesterday-evening clearing out some backlog on iio, hopefully can be back on the MDP clocks tonight
<narmstrong>
it;s fun when it's not urgent!
<Marijn[m]>
narmstrong: as far as I remember from Sunday, copying the downstream clock (from DT, not fully confident whether the driver adjusts it yet) still left Sony Xperia 5 (sm8150, CMDmode, no DSC) at 30fps, so it must be either a much larger clock in the mode, the bigger porches in the mode, or both.
<Marijn[m]>
It almost looks as if the panel misses half the frames...
<Marijn[m]>
But the output is rather... smooth...
<Marijn[m]>
narmstrong: heh you're poking away at a deadline for the sm8550 board?
<narmstrong>
Marijn[m]: you can read INTF_TEAR_INT_COUNT_VAL at 1s interval and compare the top 16bit value
<narmstrong>
this is the TEs sent by the panel
<narmstrong>
in cmd mode the FPS is set by the panel, but I don't know how to say a which refresh rate it should run at ???
<Marijn[m]>
narmstrong: I just added a print to `get_vsync_info` and made sure it gets called more often 😅
<Marijn[m]>
narmstrong: depends on the panel... for us it's all magic commands copy-pasted from downsteam. Fortunately we have some multi-rate panels where diffing gives us the commands that "change" the rate
<narmstrong>
Marijn[m]: it works :-p now perhaps you have the same issue as mine, where you get half fps
<Marijn[m]>
Exactly that, unless I poke at the mode for my panel. What's the fix? 🧐
<narmstrong>
I'll continue looking... so far all the MDP registers are the same as downstream on my side, but I think I haven't checked the MDP TOP registers
<lumag>
narmstrong, is there any topology difference?
<narmstrong>
lumag: yes, downstream uses DSC and CTL_0, CTL_0 is fine because Video mode would also be affected
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #linux-msm
<dv_>
hi, I was talking to ndec about getting compress-offload to work on the dragonboard 410c
<dv_>
I use `meta-qcom`. tried out current git master as well as kirkstone. no luck. the board boots, but there are no `/dev/snd/compr*` devices present.
<dv_>
has anyone tried to get compress-offload stuff to work on the 410c? I have seen these devices when using the pre-flashed android image, so the DSP is capable of that.
<ndec>
hey dv_ , on the 410c (with upstream linux kernel) we are by passing the DSP. the SoC on this board allows it, and the upstream audio driver does not use DSP at all. so you can't use compressed audio on this platform. srinik is our audio person, if you have additional questions.
<Marijn[m]>
lumag: for me iirc it was all dscmerge topology with dsc and pp 0,1
Daanct12 has quit [Remote host closed the connection]
pevik_ has quit [Ping timeout: 480 seconds]
swdefrgthfgjhk has quit [Remote host closed the connection]
swdefrgthfgjhk has joined #linux-msm
pevik_ has joined #linux-msm
<minecrell>
dv_, ndec: most of the patches I submitted upstream for DSP audio on msm8916 have already been applied, there is actually just the DT part missing. However, you will likely need to use some very old "modem"/DSP firmware since the current one for DB410c fails spectacularly when trying to use DSP audio there
<minecrell>
Iirc I tried the compressed audio on msm8916 at some point and it worked okay
<bamse>
minecrell: that would be because the firmware for db410c was hacked up to not touch the lpass
<minecrell>
bamse: yep, seems like whoever did that didn't spent much time on it. The APR etc stuff for the audio DSP is still being registered but things crash hard if you try to use it
<bamse>
minecrell: did they perhaps instead just change the access control?
<bamse>
minecrell: or they just crippled it?
<bamse>
minecrell: i don't remember the exact details of how that modification happened, ndec do you (and do you remember if there was a version with dsp-based audio published)?
<minecrell>
bamse: it feels literally crippled but to be fair I didn't debug it in detail
<minecrell>
bamse: I think some really old bsp zips and/or Linaro bootloader images come with DSP images where it wasn't disabled yet (but maybe I misremember). Would recommend just trying them one by one
<bamse>
question is where the change is located, and if there are any other bug fixes in the newer dsp firmware that you want
pevik_ has quit [Ping timeout: 480 seconds]
pespin has quit [Remote host closed the connection]
<Mis012[m]>
bamse: is it possible that qcom axed pin stimulation support somewhere between 8916 and 8992?
<Mis012[m]>
the devicetree has s/nidnthw/nidntsw/ and qdsd regs are missing
<Mis012[m]>
minecrell: the nice thing about db410c is that if you were to start writing hexagon fw from scratch, the only feature temporarily missing would be GPS :P
<bamse>
Mis012[m]: what's pin stimulation?
<Mis012[m]>
NINnT term
<Mis012[m]>
*NIDnT
<Mis012[m]>
basically you pump a signal into the sdcard slot that the sd controller doesn't see as anything relevant, but on the side dedicated detection hw identifies the signal and switches a mux
<Mis012[m]>
bamse: I tried to trigger the mux from Linux and got a crash, was hoping pin stimulation would *just work* but either I'm doing it wrong or it's not a thing anymore
<bamse>
Mis012[m]: i don't know how long it survived, but could be that the register is protected?
<Mis012[m]>
bamse: either that or unclocked, but pin stimulation would be preferable
<Mis012[m]>
bamse: not sure if I'm doing something wrong, no timing is specified in the docs
<Mis012[m]>
I have yet to try this on 8916, but that has a different wildcard of "did samsung decide to be dicks and disable nidnt with fuses"
<minecrell>
bamse: Can't have FastRPC and audio DSP at the same time on db410c as the former is only in the very latest firmware version and no other msm8916 has it. Otherwise it's just GPS so I doubt any bug fixes are missing there
<minecrell>
We probably have even much older firmware in some smartphones and I haven't heard of any problems with them
<bamse>
minecrell: too bad, fastrpc is a nice feature...although rather niche
<Marijn[m]>
narmstrong: as said I'm reading `INTF_TEAR_INT_COUNT_VAL` in every `dpu_encoder_phys_cmd_prepare_commit()` and it's always going up by 2, as if DPU is skipping half the frames. However, the delta between the timestamps results in 0.0.16s per increment, which is the expected 60fps on the panel itself. I do get "proper" 60fps in kmscube when bumping the pixel clock all the way from ~163MHz to ~370MHz (that "massive porches" patch shared
<Marijn[m]>
earlier)
<Marijn[m]>
narmstrong: on 30fps the panel is also tearing in the top ~30 pixels on modetest (invisible in kmscube)
<Marijn[m]>
narmstrong: and `INTF_FRAME_COUNT` is always 0 :)
<Marijn[m]>
pclk0_clk and byte0_clk in clk_summary do match the values quite closely though, so there's no strangeness going on unless dispcc is improperly describing our tree... Time for debugcc :)