<digetx_>
guess host1x stops working after resume because of the succeeding devm_request_irq(IRQF_SHARED), just to make it clear why I'm grumpy about it
jn has quit [Remote host closed the connection]
jn has joined #tegra
jn has joined #tegra
jn has quit [Changing host]
<digetx_>
although, it won't work either way; I'll continue tomorrow
indy has quit [Ping timeout: 264 seconds]
indy has joined #tegra
<cyndis>
digetx_: excellent, I'll take a look.
<cyndis>
I suppose I should be able to enable runtime PM for GR3D/GR2D locally and it should make it reproducible also
<cyndis>
oh, the host1x driver itself doesn't have pm_runtime support
<cyndis>
then we can look at this bug but I don't think it should be a blocker for the series
<cyndis>
waiter code is anyway going to be refactored
<cyndis>
though I guess if it means grate-kernel cannot downstream the new uapi then that wouldn't be good..
<cyndis>
digetx_: from what I can tell in grate there is no pm_runtime_get/equivalent call in intr.c so it's no surprise we'd go to suspend while there is a pending wait
<cyndis>
I guess in a normal situation it would be surprising that a wait would not complete in the autosuspend period, but it's not guaranteed; if there's a timeout then since there is no fast-forwarding of syncpoint increments anymore the wait will linger until timeout which very likely is past the autosuspend period
<cyndis>
though I don't know why there would be a timeout either
tagr has joined #tegra
tagr_ has joined #tegra
<tagr>
looks like this Matrix-to-IRC bridge is working \o/
<cyndis>
I think they got it working pretty recently :)
tagr_ has quit [Client Quit]
<tagr>
I've set up my own heisenbridge on a Matrix homeserver that I'm running for personal use
<tagr>
looks like it's pretty seamless, too
<tagr>
it's a bit challenging to work with, though, because of the various layers involved
<cyndis>
I see, yep, that works too. though I thought I saw somewhere that the bridge wants to connect some separate bot as well which can be a problem if you have limited connections to the network
<cyndis>
I haven't used it myself though
tagr_ has joined #tegra
<tagr>
cyndis: I think the term that's used for the kind of bridging I use is called "puppeting" where the bridge basically creates a proxy to forward the traffic
<tagr>
that avoids the need for a bot to connect
<cyndis>
okay
<tagr>
it's a bit funky the way that this works, because the heisenbridge basically "imports" IRC traffic into the Matrix native format
<tagr>
so if somebody joins, then heisenbridge will "invite" that user to the Matrix room that corresponds to the IRC channel
<tagr>
and it will then automatically create a virtual user for that and accept the invitation so that that user appears in the Matrix room
<tagr>
monitoring this conversation from a regular IRC channel, it looks like this works "as expected"
<cyndis>
interesting, I was only aware of the "proper" bridge
<cyndis>
I guess this should work as well. I think there is an official libera.chat matrix bridge now too, though it may be still in "testing"
<tagr>
disclaimer: I'm totally new to this, so no idea what's proper and what isn't
<cyndis>
by proper I mean the thing that's called just "bridge" :p
<tagr>
oh, do you mean the "standard" Matrix-to-IRC bridge?
* tagr
wanted to install that first, but it seemed really difficult to configure...
<tagr>
ha! /me works, too
<cyndis>
yeah, that is more intended as a service to be run, for a lot of channels and users. but there is a public instance of it, IIRC if you join #tegra:libera.chat in matrix it might work
<cyndis>
but last I saw note of it it was still in testing
<tagr>
and the client even gives me a bunch of fancy alternatives, such as this...
<tagr>
heh... that doesn't actually translate to IRC, it seems
<tagr>
¯\_(ツ)_/¯ guess that was because it requires actual graphics
<tagr_>
ah... /shrug works =)
tagr_ has quit [Quit: leaving]
<cyndis>
with the standard bridge, if you send images or long messages it'll translate that to links on irc side, occasionally to the annoyance of grumpy old-fashioned irc people ;)
<tagr>
mhm... after going through the configuration options of the standard bridge that certainly seemed to be the case
<tagr>
I mean, it's got tons of options to customize aliasing of IRC users/channels to Matrix users/rooms and so on
<tagr>
so yeah, I think that's meant more as a convenience for users that network operators can set up to hook everyone up to the same communication channels, no matter what client they prefer to use
<cyndis>
yeah, not intended for single users to run themselves. but a lot of people use the public bridges
<tagr>
cyndis: do you happen to know if I'm supposed to be able to connect to rooms on different servers from any Matrix homeserver?
<cyndis>
yes, that's the whole idea
<tagr>
I guess I haven't properly configured mine, because if I try to join #tegra:libera.chat, it complains that that's not available
<tagr>
well, I suppose maybe it really isn't available, but it's also possible that I've locked down my homeserver so that I can't do that
<tagr>
does this have anything to do with "federation"?
<tagr>
again, sorry, total noob here
cyndis[m] has joined #tegra
<cyndis>
yes, that's the federation feature, your homeserver will keep a connection to the other homeserver and exchange information (federate)
<cyndis>
seems to work for me ^
cyndis[m] has left #tegra [#tegra]
<tagr>
interesting... I'll have to look into that, seems like a very useful feature
<tagr>
okay... I need to restart the Matrix server to test this out... I wonder what will happen to the heisenbridge when I do that
tagr has quit [Remote host closed the connection]
<digetx_>
cyndis: the job can be unreferenced only when hw is done with it and idling, hence host1x shall idle too
<digetx_>
host1x has rpm support in grate kernel and I will be sending out those rpm patches sometime soon, maybe next week
<cyndis>
that doesn't technically mean host1x is idling, only that the engine is idling
<cyndis>
of course it seems quite rare that that would happen in a normal situation, but if you make a wait ioctl with some random id/threshold, host1x will be busy with the wait while no job is ongoing
<digetx_>
all drivers and code paths that use host1x should be using rpm that keeps host1x resumed till all its children/users are suspended, if it's not the case, then it needs to be fixed
<digetx_>
we have rpm for all engine as far as I see
digetx_ is now known as digetx
<cyndis>
RPM calls need to be added to places like host1x_intr_add_action
<digetx>
okay, perhaps will be better to remove host1x_intr_add_action first
<cyndis>
that's OK, though then we should go ahead with merging of the series
<cyndis>
for testing runtime PM can be disabled in grate kernel if you want to test within grate kernel
tagr has joined #tegra
<digetx>
I will be reviewing series soon, still there is no implicit fencing and drm-sched there, which should be essential
<cyndis>
I thought we established earlier that those are not mandatory for initial UAPI
<cyndis>
anyway the UAPI has the building blocks for those features for later implementation
<digetx>
I will need to revisit older reviews, we should need it for mesa
<cyndis>
if mesa is not working with current upstream UAPI, then it is OK to not support it initially in the new one either, as long as the extensibility is there
<digetx>
that could be a good exercise to check whether extensibility will work
<digetx>
I'm not asking you to implement it, I'll do it on top of the yours work
<cyndis>
considering the UAPI will still be under CONFIG_STAGING, perhaps we can merge this and even if we need to make some backwards-incompatible modification, it is still doable?
lahvuun has joined #tegra
<cyndis>
I did test implicit fencing earlier with this UAPI
<digetx>
I will review the v6/7, if it's okay, then I will try to add missing parts to get it all on par with the grate's experimental uapi/driver
<digetx>
you're good for now
<cyndis>
okay. I was hoping if you don't find issues with v7, we might get it in for 5.14 before my summer vacation
<cyndis>
though I'm not quite sure when the merge window for that is
<cyndis>
though maybe that's not possible anyway, I don't know who all needs to review it
ThierryReding[m] has joined #tegra
<digetx>
at least tagr, maybe kusma
<ThierryReding[m]>
aha... this seems to work now, too
<ThierryReding[m]>
some problem with TLS certificates...
ThierryReding[m] has left #tegra [#tegra]
<digetx>
is it normal that I don't see ThierryReding[m] in the list of channel users?
<cyndis>
well, he just left
<digetx>
ah
<digetx>
indeed
<tambre>
Is TA892SA-A2 (SKU 0x98) just a lower clocked variant of TA890SA-A2 (SKU 0x90)?
<cyndis>
most likely. L4T support may be able to help better there
<tagr>
digetx: yeah, I was just testing the federation feature, sorry for the noise there
<tambre>
cyndis: Neither machine I have with those SKUs is part of the Jetson lineup, so probably not. :)
<tambre>
I guess TA892SA-A2 is equivalent in meaning to Xavier-AD.
<cyndis>
ah, well, in that case you should have some other support contact :p
<cyndis>
only special SKUs I know about are 0x9E and 0x9F which only have one instance of the MM/CV engines that normally exist in a pair
<cyndis>
and that's because it's in the kernel :)
<digetx>
tagr: good to see you here
<tambre>
cyndis: Out of interest, where are those listed in the kernel?
<tambre>
I'd also wager if I went through normal support channels asking such questions I'd get weird looks and more questions asked of me than I'd get answers.
<cyndis>
mmh, that's possible :)
<cyndis>
in the drivers for those engines in linux-nvidia/drivers/video/tegra/host/...
<tambre>
Found those, thanks for the pointer!
<cyndis>
np
torez has joined #tegra
torez has quit [Client Quit]
torez has joined #tegra
<digetx>
cyndis: host1x also dies on system suspend
<cyndis>
same issue or something else?
<digetx>
seems not the same, I don't see the "host1x_intr_stop cannot stop syncpt..."
<digetx>
suspend/resume works using OPENTEGRA_FORCE_OLD_UAPI=1
<digetx>
so there are no errors on suspend/resume with v3, but host1x is toasted after resume
<cyndis>
interesting
<cyndis>
there isn't much of a change on the host1x side
<cyndis>
I'll give it a test once I get my boards working again.. I think I managed to bork my rootfs..
<digetx>
run lxde with v3 -> kill Xorg -> suspend -> resume -> start lxde -> gr3d is dead, 2d works
<digetx>
I'm also not sure why there are 4 sync points allocated for xorg
<digetx>
[ 114.657780] ---- syncpts ----
<digetx>
[ 114.658118] id 6 (6-Xorg) min 133 max 134 (1 waiters)
<digetx>
[ 114.658280] id 7 (7-Xorg) min 142 max 142 (0 waiters)
<digetx>
[ 114.657907] id 3 (3-54200000.dc) min 5742 max 0 (0 waiters)
<digetx>
[ 114.658421] id 12 (12-Xorg) min 148 max 148 (0 waiters)
<digetx>
[ 114.658642] id 13 (13-Xorg) min 0 max 58 (51 waiters)
<digetx>
I killed xorg and:
<digetx>
---- syncpts ----
<digetx>
id 3 (3-54200000.dc) min 31365 max 0 (0 waiters)
<digetx>
id 12 ((null)) min 866 max 866 (0 waiters)
<digetx>
id 7 ((null)) min 142 max 142 (0 waiters)
<digetx>
id 6 ((null)) min 133 max 133 (0 waiters)
<digetx>
that's why I want to remove all that syncpt recovery complexity that is not needed for older socs
<digetx>
such problems don't exist for the experimental grate driver
gouchi has joined #tegra
<digetx>
cyndis: which engines may need a persistent syncpoint on newer socs?
<cyndis>
it's not really about engines, syncpoints on newer socs are a system-level synchronization primitive
<cyndis>
also, I don't think the syncpoint recovery (i.e. job timeout recovery) is a fundamental problem. Even in this case if that happens something else already went wrong
<digetx>
there is no way to allocate a private sync point?
<cyndis>
what do you mean by private syncpoint?
<digetx>
are all engines virtualized or only some?
<cyndis>
depends on the configuration
<cyndis>
configurations where every engine that is capable of virtualization is virtualized certainly exist
<cyndis>
(that includes all of the "multimedia" engines)
<digetx>
does kernel know which are virtualized?
<cyndis>
it does, but if what you are getting at is that a non-virtualized engine could use an ephemeral syncpoint, that is not true since virtualization only means that the engine is shared across multiple VMs, not being virtualized does not mean that the engine results are not shared
<cyndis>
in practical terms, having any ephemeral syncpoint anywhere on T210 or later would be an huge, enormous pain in my arse
<digetx>
it's painful to deal with the current ill structured host1x code, not sure that we will manage to complete and fully test uapi with it, too many problems
<digetx>
but will see, I'll think more about it
<digetx>
and will try to start the doc about the reorganization
<digetx>
I still don't have a full picture of that paravirtualization, we will need to clarify it more
<cyndis>
it's not really paravirtualization, it's HW virtualization (like e.g. SR-IOV). I would prefer to just treat it as the driver having engines that it doesn't need to boot
<cyndis>
and on host1x side some other things like supporting a limited subset of channels, and having only a subset of syncpoints be writable
DavidHeidelberg has quit [Quit: node-irc says goodbye]
DavidHeidelberg has joined #tegra
crabbedhaloablut has joined #tegra
<digetx>
virtualization is transparent to kernel, paravirtualization requires modifications accommodating to the hypervisor
gouchi has quit [Remote host closed the connection]