<strongtz[m]>
found something with UFS on -next, I only get ~300MB/s read speed. But with ice disabled, I can get ~2.2GB/s
jhovold has joined #linux-msm
dliviu has quit []
dliviu has joined #linux-msm
pespin has joined #linux-msm
<strongtz[m]>
why is the unprepare() function in my panel driver called after the DSI controller is powered off :(
<strongtz[m]>
I already have prepare_prev_first set
<konradybcio>
there's .unprepare and .poweroff or something.. and IIRC it was very messy
<konradybcio>
maybe narmstrong can help you
<Marijn[m]>
strongtz: yeah iirc there was a patch/documentation stating that prepare_prev_first should affect the disable path
<Marijn[m]>
That's what my almost-1-year-old panel series is blocking on: I don't want to unbalance the DSI calls between prepare() and unprepare() (by moving them to disable())
<strongtz[m]>
yeah seems like renaming .unprepare to .disable works at least, but it doesn't look very nice
<z3ntu1>
anyone tried linux-next lately? Getting [ 25.570158] dsi_link_clk_set_rate_6g: Failed to set rate pixel clk, -22 and display doesn't work
<strongtz[m]>
my simple non-DSC video mode 1080p panel works on next-20240102
<z3ntu1>
I'll test a bit more what could cause this, anyways I'm on 20240105
<aka_[m]>
it probably boils down to clk_core_set_rate_nolock and all einvals i see is
<aka_[m]>
top = clk_calc_new_rates(core, req_rate);
<aka_[m]>
try logging what kind of rate it wants to set
<konradybcio>
Luca Weiss: bisect time?
<z3ntu1>
I went down to determine_rate or something returning -EINVAL also
<z3ntu1>
bisect is annoying because display is not upstream yet.. but just sent a patch so in the future it should be easier
<z3ntu1>
and git diff didn't show me anything obviously wrong somewhere, most of clk hasn't really changed to -next
<konradybcio>
you can use a .dtb while bisecting the kernel binary
<z3ntu1>
but also panel driver 🤷
<z3ntu1>
need to finish some other stuff first though
mripard has quit [Remote host closed the connection]
novaandromeda has left #linux-msm [#linux-msm]
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
<Adrian[m]>
For reference this is the file from the UEFI
<Marijn[m]>
Adrian: it could be a panel-specific command, but most likely is a special marker for the UEFI firmware, I think to encode a timeout in milliseconds
<Marijn[m]>
That almost matches the commands shown in DT. E.g. a 50ms after exiting sleep mode (05 11), etc
<Adrian[m]>
Marijn[m]: Oh yeah that would make sense, sleeping for 80ms would seem logical here. I wonder what else in the UEFI panel description is supposed to make it initialize in 24 bpp then? The other init sequence parts match downstream :/
<Marijn[m]>
* That almost matches the commands shown in DT. E.g. a 50ms after exiting sleep mode (05 11), a 14ms sleep after display off (05 28), etc
<Marijn[m]>
* That almost matches the commands shown in DT. E.g. a 0x50ms after exiting sleep mode (05 11), a 0x14ms sleep after display off (05 28), etc
anholt_ has joined #linux-msm
<Marijn[m]>
Adrian: one thing that confuses me in your driver is a bpp of 8. It probably changes how the DSC stream is encoded and interpreted, but the amount of DSI data should remain the same (that might throw the existing clock math off _even further_). It would also/however affect how the DSC block interprets/treats an incoming plane, but there's no upstream support for `DSI_FMT_RGB101010`.
anholt has quit [Read error: Connection reset by peer]
<Adrian[m]>
The downstream code for DSI_FMT_RGB101010 mentions that it compresses down to 8bpp as far as I remember when I last looked at it
<Marijn[m]>
Adrian: if you only set `bpc` to 8, the "not supported" error should be gone, and you're only left with timeouts right? I'm not sure if DSC merge concatenates vertical blocks, and have so far only seen panels with a slice width of half the panel. The current kernel is hardcoded to a 2:2:2 merge topology, but you might need a singular 1:1:1 topology