user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi-dev
yuyichao has joined #asahi-dev
phiologe has joined #asahi-dev
PhilippvK has quit [Ping timeout: 480 seconds]
yuyichao has quit [Quit: Konversation terminated!]
yuyichao has joined #asahi-dev
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #asahi-dev
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
timokrgr has quit [Remote host closed the connection]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
nicolas17 has quit [Quit: Konversation terminated!]
millenialhacker has joined #asahi-dev
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
millenialhacker has quit [Ping timeout: 480 seconds]
Skirmisher has quit [Remote host closed the connection]
Skirmisher has joined #asahi-dev
millenialhacker has joined #asahi-dev
<jannau>
marcan: how much effort is it to recreate KNOWN_MSGS in trace_dcp.py? I think '"A103": "IOMFB::UPPipe2::test_control(IOMFB_TC_Cmd, unsigned int)"' doesn't exists anymore
<jannau>
signature still matches but looks more like it should be 'A103 = Call(void, "get_config_frame_size", width=InOutPtr(uint), height=InOutPtr(uint))'
<jannau>
the next two calls set_config_frame_size and program_config_frame_size are consistent with one removed call
<jannau>
not a particularly important task but it's impossible to tell from traces what happened to unobserved calls/callbacks
<jannau>
the next observed Call A131 doesn't look obviously wrong judging by context
<jannau>
at least dpms and switching between 2 different seems now to work reliable
<j`ey>
between 2 different whats?
<jannau>
displays
<j`ey>
with different resolutions?
<jannau>
yes, a cursed dell 4k display and a well behaved FullHD display
<sven>
sounds like we have the same dell display :D
<jannau>
kde system settings seems to get confused about the refresh rates though. 4k is limited to 30 Hz due to HDMI 1.4 but it offers 60, 50 and 24 Hz instead of 30, 25 and 24
millenialhacker has quit [Remote host closed the connection]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<j`ey>
sven: r-b by hch.. nvme seems pretty close now!
<sven>
yeah, just dt-bindings and SART/rtkit now :)
<sven>
in other news, acio ofc has another tunable format compared to atcphy *sigh*
<j`ey>
talking of tunables, I get this warning when building m1n1 now, not sure which type should be changed:
<j`ey>
src/kboot.c:710:51: warning: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘const long unsigned int’} [-Wsign-compare]
<marcan>
I suspect that's wrong since DART_PTE_VALID sets both bits
<marcan>
we might be mapping the *page tables* themselves as RT
<marcan>
or maybe they are supposed to be RT, and having them in CPU cache also is a no-no?
<jannau>
the page table itself is initialized by iboot
<marcan>
but we write it, right?
<marcan>
so we probably need to map it uncached
<millenialhacker>
Hi! here working on ISP, I notice a memory address which gets written always with a incrementing value but step between value and value is not constant. Have you ever seen a similar pattern?
<sven>
could be a ringer buffer that gets advanced, or maybe some timeout. hard to tell without context
<jannau>
I tried that and it didn't made a difference
<sven>
that address is *read* and increases. looks like a counter at first glance
<jannau>
also bit 1 (uncached for t6000/t8110) is not set: table (0): 00000000 ... 02000000 -> 0000010ffff44000 [01]
<millenialhacker>
sven: ring stuff makes sense, it always come back to lower addresses after some time
jluthra has quit [Remote host closed the connection]
<jannau>
marcan: dcp method annotations are good, I haven't spotted any other inconsistencies. thanks
jluthra has joined #asahi-dev
nihilistpc[m] has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
<millenialhacker>
sven: definely some kind of counter, timer, each 3 mins it does a full cycle and next subsequent word (+4 bytes) get incremented in one.
<sven>
sounds like some timer based on that 24 MHz clock then
<millenialhacker>
sven: how did you get is related to 24Mhz clock?
<millenialhacker>
Sorry for the question, just curious, trying to learn here
<jannau>
should loop every 178.957 seconds
<sven>
because 2**32 ticks with a 24 MHz frequency take about 3 minutes ;)
<j`ey>
and there is a 24Mhz clock that's used by several things already!
<sven>
and I just happened to know that by heart because I wrote the watchdog driver where I did that calculation
<millenialhacker>
holy cow guys, I didn't spot that one
<millenialhacker>
I was planning to count number of reads per second
<millenialhacker>
but I'm almost sure all of you are right, so no need to do the math
<millenialhacker>
D:
<sven>
you already know that a full cycle takes 3 minutes. a full cycle is 2**32 events, i.e. 2**32 / 3 minutes which is ~24 MHz
<sven>
(note that it's actually not a full cycle but a 64bit counter but same difference)
<millenialhacker>
sven: yeah, it seems next 4 bytes are just the upper bits of the 64 bit counter
<millenialhacker>
should I document that stuff, right?
<j`ey>
yep
kaprests has quit [Ping timeout: 480 seconds]
<marcan>
jannau: fixed the macos thing. It's what I said; we need to map the pagetables as UC, since DART page table walks count as part of the realtime path, same as the framebuffer itself, and cannot hit the CPU cache.
<marcan>
there's a flag in pmap-ranges that I'm guessing tells us that; alternatively we could use the real-time DART property and the l2 ranges thing
<marcan>
this won't work (right now) if we have to allocate our own page tables, of course
<jannau>
marcan: thanks. format check failed
bps has quit [Ping timeout: 480 seconds]
nicolas17 has joined #asahi-dev
<marcan>
right..
<j`ey>
ooh tick polling
<marcan>
or rather, not
<marcan>
jannau: hopefully HV should scale to t6002 core counts better now
<marcan>
it no longer tries to take a single lock 20000 times per second :p
<marcan>
(only 1000 and from the same CPU in the easy case)
MajorBiscuit has quit [Ping timeout: 480 seconds]
<sven>
someone should pick up that t6k dart series and correctly add support for that new PTE format now that we know these bits
<marcan>
yeah
<marcan>
though the uncached bit seems unrelated here?
<sven>
iirc there’s a flag that can be passed to map something as uncashed
<marcan>
the issue I fixed was just the MMU mappings
<sven>
oh, just in general
<marcan>
not sure exactly how that uncached bit interacts
<marcan>
but yeah
<sven>
read/write protection also changed iirc
c10l684 has quit []
c10l684 has joined #asahi-dev
<jannau>
marcan: yes, macos HV is much faster. linux seems to be faster as well although it was less noticeable
<jannau>
only annoying case was window resizing/moving which could have been caused by dcp tracing
<marcan>
everything should be faster in general, I think macos is just heavier so becomes even worse when everything is fighting
<marcan>
jannau: whoops, forgot a thing, pushed a fix
<marcan>
hopefully I didn't slow it down again :)
<marcan>
(it wasn't properly running the tick on secondaries)
c10l684 has quit []
c10l684 has joined #asahi-dev
c10l684 is now known as c10l
<marcan>
heh, missed a thing, force-pushed the fix to properly fix it now
lgaryslmtdobt^ has joined #asahi-dev
<jannau>
shutdown/restart is slower but still reasonable fast
<millenialhacker>
regarding isp, I noticed a pattern of access some memory regions that get's repeated over and over. :D
<millenialhacker>
I actually copy pasted the logs, and then selected like 50 lines of memory accesses and then find them using VSCode and they get repeated over and over.
<millenialhacker>
so I'm wondering if this could be some kind of polling between host and ISP
<millenialhacker>
holycow, I think the pattern repeats over each camera frame
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
timokrgr has joined #asahi-dev
lgaryslmtdobt^ has quit [Remote host closed the connection]
HaDongGiang[m] has joined #asahi-dev
HaDongGiang[m] is now known as virmos[m]
user982492 has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
<sven>
urgh... usb4/thunderbolt is going to be nvme all over again. the current driver only supports PCI.
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
user982492 has quit []
<kettenis>
sven: took me a few seconds to realize what you were trying to say there
<sven>
ah. yeah, that sentence is more than a bit confusing.
<maz>
sven: hopefully there will be less opposition this time around. I remember looking at the Corellium hack, and it didn't seem to have a massively different programming interface.
<jannau>
is there even usb4/thunderbolt HW beside Intel (and apple)? zen4 will be pcie based too