thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
jacobcrypusa[m] has left #asahi-dev [#asahi-dev]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Read error: Connection reset by peer]
thelounge7571340 has joined #asahi-dev
skipwich has quit [Quit: DISCONNECT]
kov has quit [Quit: Coyote finally caught me]
chadmed has quit [Ping timeout: 480 seconds]
nicolas17 has quit [Quit: Konversation terminated!]
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
OfirRubenov[m] has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
SSJ_GZ has joined #asahi-dev
thelounge7571340 has quit [Read error: Connection reset by peer]
<jannau>
still no update from Joerg
thelounge7571340 has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
<sven>
huh, if I bring up atcphy for thunderbolt and then enable acio the pciec mmio becomes accessible... so why doesn't that happen inside linux as well?!
<sven>
jannau: :(
<sven>
maybe he's on vacation or sick or something like that
<_jannau_>
probably, he was planning to look at the t600x dart series last week
<_jannau_>
maybe a power-domain that gets disabled in linux?
thelounge7571340 has quit [Read error: Connection reset by peer]
<j`ey>
I wonder if there is a power domain equivalent to clk_ignore_unused
<sven>
hm... let me check that. maybe i'm just missing some domain in my hacked up device tree
thelounge7571340 has joined #asahi-dev
<sven>
j`ey: I guess I could mark all of them as always on :D
<sven>
looks like there's pd_ignore_unused though
<j`ey>
give it a try!
<steev>
yeah pd_ignore_unused is power domains
<sven>
same result, I guess there's a subtle bug in my atcphy.c then :(
<j`ey>
can you trace it?
<sven>
yeah
jluthra has quit [Remote host closed the connection]
<sven>
still going to be annoying to figure out the difference to my python code
jluthra has joined #asahi-dev
<sven>
I guess I could run m1n1 inside the hv and then run atcphy.py against that el1-m1n1 and trace it with el2-m1n1 and look for differences
<j`ey>
I guess double check the register offsets/values is a good place to start too
<sven>
yeah, i bet it some BIT() #define that's wrong
<sven>
*it's
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
roxfan has quit [Remote host closed the connection]
roxfan has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
duban6 has quit []
duban6 has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
chengsun_ has joined #asahi-dev
chengsun has quit [Ping timeout: 480 seconds]
nickchan has joined #asahi-dev
nickchan has quit []
Major_Biscuit has joined #asahi-dev
Major_Biscuit has quit []
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
gilutsu_test03[m] has joined #asahi-dev
gilutsu_test03[m] has left #asahi-dev [#asahi-dev]
<sven>
[syslog] * [PmgrService.cpp:319][AFK]_pmgrConfigVideoClock Failed to configure video clock freq= 74250000
<sven>
hrm
<sven>
selecting different modes doesn’t seem to help either :(
<jannau>
"VideoInterfaceIOAV::open_ioav_gated(): IOAVVideoInterface open failed" sounds broken as well
<jannau>
can you test dcpep instead of dcp_iboot?
<sven>
not easily, I’ll have to untangle some of this mess first
<jannau>
which mode did you set? 1920x1080@30 or 1280x720@60
<sven>
in that trace 1920x1080@60, then later I tried @30 and some other random lower resolution mode
<jannau>
74.25 MHz would be CEA-861 pixel clock for 1920x1080@30 or 1280x720@60
<sven>
huh, weird
<sven>
Chosen timing mode claims fps_int = 60 though :/
<sven>
(At 1920x1080)
<sven>
[syslog] * [PmgrService.cpp:319][AFK]_pmgrConfigVideoClock Failed to configure video clock freq= 13500000 <-- that's with 1440x480@29
<sven>
[syslog] * [PmgrService.cpp:319][AFK]_pmgrConfigVideoClock Failed to configure video clock freq= 37087912 <-- and that with 1920x1080@29
<jannau>
so it's ~2 off, strange
<jannau>
+factor
<sven>
yeah. i'll double check my atcphy configuration
<sven>
but maybe the iboot protocol just doesn't work with dcpext for some reason
<sven>
it also reliably oscillates between "no color modes" and "valid colors modes" so there's still something that's obviously broken
thelounge7571340 has quit [Remote host closed the connection]
<jannau>
not sure how the pixel clock calculation should be dependent on the atc phy config. it should just depend on the selected mode
<sven>
knowing how entangled that mess is it wouldn't have surprised me
<sven>
there's some PCLK (which I assume means pixel clock) configuration inside atcphy and something else that depends on the link rate
<sven>
but it doesn't look like there's an additional diver or multipler to be configured
thelounge7571340 has joined #asahi-dev
<jannau>
let me check what the dcp does with the pixel clock. I remember that it was not what I expected but since it works I didn't pay attention what was off
min[m] has joined #asahi-dev
<jannau>
no, I misremembered. pixel clock is as expected for h/v total pixels and refresh rate
<sven>
real dcp protocol seems to first print [syslog] * [nifiedPipeline.cpp:6553]set_digital_out_mode returned 80000104
<sven>
and then
<sven>
while mgr.iomfb_prop['DPTimingModeId'] != timing_mode:
<sven>
KeyError: 'DPTimingModeId'
<sven>
ahh.. nvm
<sven>
also fails with [syslog] * [PmgrService.cpp:319][AFK]_pmgrConfigVideoClock Failed to configure video clock freq= 74250000
<jannau>
it logs however a vid0 value which is half rate of the pixel clock: "syslog message: ock_Config_H13P.cpp:886: program_frame_size: pixel_clock 265250000, vid0 132625000, 000084a0 000001ef"
<sven>
i think it currently fails before that
<sven>
real dcp seems to always get the correct mode list though fwiw
<sven>
so maybe the iboot code has a weird race somewhere
<sven>
so this is either some subtle DCP issue or some subtle ATCPHY issue. i actually don't know which would be worse :(
<jannau>
full dcp seems to have "IOMobileFramebufferAP::setProperty_int(key='VideoClock', value=74250000)" in a log which should be 1920x1080@60. resolution is certain, but I can't easily see the display refresh rate
<sven>
so that would match [syslog] * [PmgrService.cpp:319][AFK]_pmgrConfigVideoClock Failed to configure video clock freq= 74250000 at the same resolution here
<sven>
same thing happens when I just replay the hv trace instead of using my atcphy code
<jannau>
yes. so there's a video clock which runs at half-rate of the pixel clock
<sven>
why doesn't it just work then =(
gladiac has quit [Quit: k thx bye]
<jannau>
have you checked pmgr with tools/dump_pmgr.py?