<lumag>
Marijn[m], konradybcio: just to check: is anybody working on sm8250-debugcc?
pevik_ has joined #linux-msm
<ndec>
bamse: minecrell : the Android BSP (downstream) for the 410c uses (and contains) the DSP firmware with audio support. Back in these days we had no hope we could support the DSP based audio software stack, an found that on 8916 it was possible to bypass the dsp (LPASS is accessible from MPU). But iirc it is pretty much the only platform where it's possible to bypass the dsp
<ndec>
then we ended up (well srinik ...) writing the DSP based audio drivers for other platforms. so 8916/410c is effectively an 'odd' one upstream
<minecrell>
ndec: Well I think the DSP audio bypass is a good thing personally (it has more control about audio sample rate/format etc). It's not that odd anymore since the Chromebook platforms also do that now
<Marijn[m]>
lumag: I can compare and test my 8150 addition with 825
<lumag>
Marijn[m], if you have time
<lumag>
I was surprised to see sm8[134]50, but no sm8250 ;-)
<Marijn[m]>
lumag: I was surprised to not see sm8150 :)
<Marijn[m]>
But my 8250 device was on the other side of the room and it was 2am...
<lumag>
sm8150 was kind of a foster child.
<lumag>
The was no dragonboard, no RB device, so it was partially skipped
<lumag>
Heh. It seems vger.kernel.org stopped processing mails
<Marijn[m]>
lumag: indeed, besides QCOM reference boards only Sony Xperia edo uses sm8250
<Marijn[m]>
But looking at Makefile there are quite a few Sony-dominated SoCs upstream...
pg12_ has quit []
pg12 has joined #linux-msm
<Marijn[m]>
lumag: sm8250 debugcc is totally different from 8150, I'll see about porting it tonight :)
<lumag>
Marijn[m], thanks a lot!
<Marijn[m]>
narmstrong: I've been thinking about looking at ftrace to see whether vsync interrupts are arriving and where we're missing half the frames
<lumag>
we should probably put a policy that gcc-SoC.c comes together with SoC-debugcc.
<lumag>
:D
<narmstrong>
Marijn[m]: I've set the display in autorefresh and I've seen the same rate change in INTF_FRAME_COUNT
<narmstrong>
so I think it's not sw related
<narmstrong>
well it is, but a hw config inssue somewhere
<narmstrong>
like a /2 set somewhere that should not be here for command mode
<Marijn[m]>
narmstrong: I hope some of my DCS turn autorefresh off (not sure if/how relevant it is when the panel refreshes at 60FPS, when also receiving new frames at 60FPS...)
<Marijn[m]>
lumag: yes but sm8250 upstream has 9 clock controllers ;)
<lumag>
narmstrong, Marijn[m]: just to check are you trying the single-link DSI or dual DSI panel?
<Marijn[m]>
Having it ported from the get-go would be great though, good to have this feedback
<Marijn[m]>
narmstrong: unless CMDmode (though this must be driven by userspace) does damage updates?
<Marijn[m]>
lumag: single link on everything
<narmstrong>
lumag: single link
<Marijn[m]>
If I remember correctly only MSM8998 Xperia Maple (XZ1) uses dual-link, the rest is all single-link DSI (with DSC for 4k 120Hz :P)
<narmstrong>
Marijn[m]: what are you using for your tests ?
<Marijn[m]>
narmstrong: debugcc to look at the clocks, pr_err in various driver bits (not too many or it affects framerates), and then kmscube or modetest
<Marijn[m]>
narmstrong lumag: kmscube is more convenient because it auto-picks the mode... modetest needs the (only!) mode set explicitly and my shell history always contains the wrong one (1660p, 2520p, 2560p...)
<Marijn[m]>
1440p*
<lumag>
Marijn[m], what exactly is the issue?
<lumag>
No image, stalls, etc?
<narmstrong>
Marijn[m]: you can try `modetest -r` to autoset the default prefered mode :-p
<Marijn[m]>
lumag: userspace sees only 30FPS vsync (sm8150, cmdmode panel, no DSC) but INTF_TEAR_INT_COUNT_VAL goes up at 60Hz...
<lumag>
Marijn[m], and image is displayed correctly?
<Marijn[m]>
lumag: well... kmscube yes, but only because the cube is small and in the center. On modetest the SPMPTE has tearing in the top ~30-50 pixels
<Marijn[m]>
If I double the clocks everything becomes fine
<Marijn[m]>
I have a Sony Xperia 10 II (sm6125) with an identical screen, there everything works fine (without bumping clocks... it cannot even achieve those)
<Marijn[m]>
narmstrong: but I'm using `-v` to test vsynced page flipping, and... `page flipping requires at least one -s option.`
<narmstrong>
Marijn[m]: yep i know it's a shame, I should send a patch to fix this, `-r -v` would be great
<Marijn[m]>
So it forces me to set a mode... Maybe an upstream bug/inefficacy that we should fix?
<Marijn[m]>
narmstrong: `-a` for atomic API also immediately exits
<narmstrong>
Marijn[m]: yep -a never worked for me on any platforms, so I wonder how to use it
<Marijn[m]>
It gives different output when leaving -v out... But a static image is mostly useless for us
<lumag>
Strange. kmscube -a works for me
<Marijn[m]>
So it does work, just not for vsynced page flipping... And that's exactly the feature I need to test
<Marijn[m]>
lumag: together with `-v`?
<lumag>
yep
<lumag>
rb3
<lumag>
kmscube -a -v 1920x1080
<lumag>
I think I have surfaceless patch applied, maybe that makes the difference.
<narmstrong>
lumag: rb3 is sm8150 right, but you which video output ? DSI panel ? DSI hdmi ?
<lumag>
sdm845
<lumag>
DSI<->HDMI via the lt9611 bridge
<narmstrong>
yep ok, so it's video mode
<lumag>
Yep. I was worried about '-a exits immediately'
<lumag>
And so went on checking
<narmstrong>
lumag: it's with modetest
<Marijn[m]>
lumag: `modetest -M msm -a -v 1080x2520` gives `page flipping requires at least one -s option.` for me, did you miss the `-s` for the mode (and connector id?)
<lumag>
Ah. With modetest you also have to add a plane
<lumag>
modetest -s 32:3840x2160 -a -P 69@81:1920x1080
<narmstrong>
Marijn[m]: looking at modetest souce, there's no point for `page flipping requires at least one -s option`
<narmstrong>
hmm no, -s will use the primary plane
<lumag>
I think there are no primary planes with -a
<narmstrong>
ah it would explain everything
<lumag>
I can use 69, leaving primary plane 33 in place, or I can use 33 (primary plane for CRTC 81), making it appear on the black screen
<lumag>
Marijn[m], just to check. Which clocks do you bump? The crtc clocks in dpu_core_perf?
<Marijn[m]>
lumag: right, `-a` requires `-P`, now it "works": `modetest -M msm -a -v -s 31:1080x2520 -P33@81:1080x2520`
<lumag>
:-)
<Marijn[m]>
lumag: I return double rate from `dsi_get_pclk_rate` (so that is pclk), and results in byte0_clk to be bumped as well
<Marijn[m]>
lumag: for modetest, atomic API doesn't flip a blank inbetween, so the image on the screen is effectively static (and would be impossible to notice tearing I think)
<narmstrong>
lumag: I was wondering if the DPU clocks wasn't too low, dowstream does some QoS on the frame time on CMD mode
<lumag>
narmstrong, good question. I checked the core_perf, but didn't spot anything obvious
<lumag>
As for QoS/LUTs... I think that part _can_ be damaged/broken.
<lumag>
I never dived into that part of the code. And I know that there are omissions there.
<narmstrong>
Marijn[m]: just found you can use `modetest -s 32:#0 -v` to use the first mode
<narmstrong>
trying to get `-r -v` work but there's something fishy somewhere
<z3ntu>
What does debugcc do / what is it useful for?
<aka_[m]>
z3ntu: monitoring clocks i think
<narmstrong>
yep it uses the clock measurer un HW to get the physical rate
<z3ntu>
so kind of making sure clock driver does the correct things?
<Marijn[m]>
narmstrong: it reads it from gcc though and then applies multipliers itself, doesn't it?
<Marijn[m]>
z3ntu: yes, so that one can validate without oscilloscope and ripping off the back of a phone what the clocks are doing
<Marijn[m]>
narmstrong: oh I'll set that #0 in my history, thanks!
<narmstrong>
Marijn[m]: it really uses am hw block that measures the physical freq
<narmstrong>
there's no sw calculation
<narmstrong>
except transforming the hw measure into Hz
<z3ntu>
sounds neat
<Marijn[m]>
narmstrong: right yes, that comment doesn't make much sense because the multipliers/dividers are hardcoded for all clocks in a block
<Marijn[m]>
So there's a physical line going from every clock controller to the hardware block (embedded in gcc it seems) that does the counting?
<Marijn[m]>
narmstrong: I think I never tried `#0` because the docs don't mention `<mode>` is optional
<Marijn[m]>
narmstrong: if you're making changes (feel free to ping me in the MR), can you change `[#<mode index>]<mode>` to something like `[#<mode index> | <mode>]` or whatever is the right way to express the OR here?
<Marijn[m]>
narmstrong: I'll check it out, looks complicated indeed
<Marijn[m]>
narmstrong: by the way, since you mentioned a magic debug register a while ago, and abhinav__ is still focussing on DSC 1.2, could you perhaps look at the dumps in https://gitlab.freedesktop.org/drm/msm/-/issues/24 and tell me if that magic register is saying anything conclusive that I should look into next?
<Marijn[m]>
narmstrong: Any idea why `-r` cannot be used with `-P`?
<Marijn[m]>
Fwiw it seems the modeset is optional (when already left in the right mode) to atomically set/present a plane
<Marijn[m]>
(I messed up the -s argument when using -P, and it was still showing the plane accordingly)
<narmstrong>
hmm I think it's not mode the case
<narmstrong>
let me try and remove the check
<narmstrong>
Marijn[m]: let me look at the reg dump to see if I find something
<narmstrong>
Marijn[m]: I've update the MR, and now it works with -P :-p
<Marijn[m]>
narmstrong: great, thanks!
<Marijn[m]>
Hmm, setting -P without -a (without your MR) gives a blue diagonal gradient instead of SMPTE
<narmstrong>
can you share the full command ?
<Marijn[m]>
narmstrong: `modetest -M msm -P33@81:400x400`, with or without `-s 32:#0`
<Marijn[m]>
I get more colors when choosing a bigger resolution; guess is the format is just mismatched?
<narmstrong>
oh yes I think it's expected, it selects a different gradiant if the format has transparency or not and if it's a primary plane or overlay
<narmstrong>
the logic is weird
djakov has quit [Remote host closed the connection]
djakov has joined #linux-msm
<aka_[m]>
So dsi will work oob then in next kernel?
<aka_[m]>
Or its fix so it will be backported?
<aka_[m]>
lumag: regarding byte intf patch we might want to test it against 660
alexeymin has quit [Quit: No Ping reply in 180 seconds.]
alexeymin has joined #linux-msm
pevik_ has quit [Ping timeout: 480 seconds]
pespin has quit [Remote host closed the connection]
pevik_ has joined #linux-msm
pevik_ has quit [Ping timeout: 480 seconds]
<aka_[m]>
uh
<aka_[m]>
Marijn: you are kind of display guy, any idea how can te work if downstream define wrong function for pin?
<aka_[m]>
i work on base dts for some galaxy tab guy and fdt says te pin is 73 with mdp_vsync function but pinctrl does not offer such function on this pin
<aka_[m]>
uh appears its not wired anywhere
<aka_[m]>
either is pmx_sde
<aka_[m]>
nani
<aka_[m]>
we have to resort to legacy methods it appears