Displays both owner/user of the falcon (when they differ), and takes
both subdevs' debug levels into account when deciding whether to log
the message.
- runlist debugging will use one of the alternate macros added here
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
This wasn't really needed before; the main place this could race is with
channel recovery, but (through potentially fragile means) shouldn't have
been possible.
However, a number of upcoming patches benefit from having better control
over subdev init, necessitating some improvements here.
- allows subdev/engine oneinit() without init() (host/fifo patches)
- merges engine use locking/tracking into subdev, and extends it to fix
some issues that will arise with future usage patterns (acr patches)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
- new-style handlers can now be used here too
- decent clean-up
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
- reads vectors from HW, rather than being hardcoded
- removes hacks to support routing via old interfaces
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
- switches ampere over now, and removes its hack mc implementation
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Initially for NV_USERMODE class, and Turing/Ampere's new interrupt tree.
v2. fixup for ga103 early merge
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It's quite a lot of tedious and error-prone work to switch over all the
subdevs at once, so allow an nvkm_intr to request new-style handlers to
be created that wrap the existing interfaces.
This will allow a more gradual transition.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Turing adds a second top-level interrupt tree in HW, in addition to the
trees available via NV_PMC. Most of the interrupts we care about are
exposed in both trees, but not all of them, and we have some rather
nasty hacks to route the fault buffer interrupts.
Ampere removes the NV_PMC trees entirely.
Here we add some infrastructure to be able to handle all of this more
cleanly, as well as providing more explicit control over handlers.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Unifies the handling between PCI-based and Tegra GPUs, and makes more
explicit/obvious where device interrupts can be expected.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
We're going to want this information available earlier than it is now.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
The vblank and nonstall events have some annoying interactions with DRM
locking, and aren't able to do certain things as a result.
However, other uses of event notifications don't have such requirements,
and upcoming patches take advantage of this for various improvements.
Having separate classes for each nvkm_event's spinlocks allows lockdep
to distinguish between them and avoid false-positives.
v2: __always_inline + comment
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
This removes some now-unnecessary nesting of workqueues.
v2:
- use ?: (lyude)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Also fixes vblank interrupts being left enabled when they're not meant
to be as a result of races/bugs in previous event handling code.
v2:
- use ?: (lyude)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
This replaces the twisty, confusing, relationship between nvkm_event and
nvkm_notify with something much simpler, and less racey. It also places
events in the object tree hierarchy, which will allow a heap of the code
tracking events across allocation/teardown/suspend to be removed.
This commit just adds the new interfaces, and passes the owning subdev to
the event constructor to enable debug-tracing in the new code.
v2:
- use ?: (lyude)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
This moves control of link retraining in response to HPD IRQ to the
KMS driver's HPD IRQ handler.
NVKM still handles checking link status for the moment, this can be
moved to the KMS driver when it takes explicit control of link rate
selection.
v2:
- skip source config on retrain (fixes some retrain failures)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
This removes the need for NVKM to track DP HPD events, as the KMS
driver follows them already, and has better information available.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Aside from fixing MST->SST switching (KMS never turned off MST link config),
this should preserve existing behaviour for the moment, but provide a path
for the KMS driver to have more explicit control of the DP link, which has
been requested by Lyude.
More research into modeset/supervisor interactions is needed before we can
have fully explicit control from the KMS driver.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
v2:
- fix typo in sorhdmi/g84 struct initialiser (kbuild test robot)
v3:
- less convoluted flow control in nvkm_uoutp_mthd_acquire_tmds() (lyude)
v4:
- we don't support hdmi on original nv50, don't try
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
There are various pieces of information we pass to NVKM about the next
modeset, which are generally used while handling supervisor interrupts.
We had to start passing in some information about audio requirements a
while back to allocate an appropriate SOR in ACQUIRE, so we may as well
move all this type of information here for other protocols too.
Certain methods will be blocked on non-acquired outputs now, preventing
NULL pointer derefs from KMS driver bugs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Will be used to more cleanly implement existing method interfaces that
take some confusing (IEDTkey, inherited from VBIOS, which RM no longer
uses on Ampere) match values to determine which display path to operate
on.
Methods will be protected from racing with supervisor, and from being
called where they shouldn't be (ie. without an OR assigned).
v2:
- use ?: (lyude)
v3:
- fix return code if noacquire() method fails
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Will be used to protect NVIF_CLASS_OUTP method calls from racing with
in-progress supervisor handling.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
And use it to bail early in DP detection and avoid futile AUX transactions.
This could be used on other connector types too in theory, but it's not
something we've ever done before and I'd rather not risk breaking working
systems without looking into it more closely.
It's safe for DP though. We already do this by checking an AUX register
that contains HPD status and aborting the transaction. However, this is
much deeper in the stack - after taking various mutexes, poking HW for no
good reason, and making a mess in debug logs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Will be used to provide more solid driver interfaces in general, but
the immediate motivation is work towards fixing issues with handling
hotplug/DP IRQ events.
Its use is currently limited to where we support non-polled hotplug
already (ie. any GPU since NV40ish era, where our DCB handling works
well enough), until that gets cleaned up someday.
v2:
- use ?: (lyude)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Replaces a bunch of unnecessarily duplicated boilerplate in per-chipset
code with a simpler, common, implementation.
Channel "awaken" notify code is completely gone for now. KMS has never
made use of it so far, and event notify handling is about to be changed
in general anyway.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
No changes to code at all here, just shuffling it around and removing
a bunch of (now unnecessary) forward-declarations from headers.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
About to expose head/output path/connector objects everywhere, so we will
need support for child classes prior to nv50 now.
Somewhat cleaner than the code >=nv50 used previously.
v2:
- use ?: (lyude)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Dump of one struct's members into another, with a couple of list
renames because of collisions.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
There's plenty of ways to fudge the GPU when developing on nouveau by
mistake, some of which can result in nouveau seriously spamming dmesg with
fault errors. This can be somewhat annoying, as it can quickly overrun the
message buffer (or your terminal emulator's buffer) and get rid of actually
useful feedback from the driver. While working on my new atomic only MST
branch, I ran into this issue a couple of times.
So, let's fix this by adding nvkm_error_ratelimited(), and using it to
ratelimit errors from faults. This should be fine for developers, since
it's nearly always only the first few faults that we care about seeing.
Plus, you can turn off rate limiting in the kernel if you really need to.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20220429195350.85620-1-lyude@redhat.com
