What currently works:
* i915
* nouveau
* amdgpu (isn't tested yet, but builds)

What doesn't compile/isn't tested quite yet:
* radeon

Majority of the rework done, next steps:
* Test nouveau with changes
* Test amdgpu with changes
* Remove code from radeon now that we've determined it is indeed broken
* Investigate amdgpu hacks a bit, and see if we can get rid of any of them
* Move link rate info out of mst_mgr, not really helpful and we probably
  just can get by with having pbn_div in the mst atomic state

Since we're going to be relying on atomic locking for payloads now (and the
MST mgr needs to track CRTCs), pull in the topology state for all modesets
in nv50_msto_atomic_check().

Signed-off-by: Lyude Paul <lyude@redhat.com>

It looks like that when we moved nouveau over to using drm_dp_aux_init()
and registering it's aux bus during late connector registration, we totally
forgot to fix the failure codepath in nouveau_connector_create() - as it
still seems to assume that drm_dp_aux_init() can fail (it can't).

So, let's fix that and also add a missing check to ensure that we've
properly allocated nv_connector->aux.name while we're at it.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: fd43ad9d ("drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister")
Cc: <stable@vger.kernel.org> # v5.14+

TODO: Finish writing commit message by adding refs

We want to start cutting down on all of the places that we use port
validation, so that ports may be removed from the topology as quickly as
possible to minimize the number of errors we run into as a result of being
out of sync with the current topology status. Let's do this with CSNs by
moving some code around so that we only queue link address probing work at
the end of handling all CSNs - allowing us to make sure we drop as many
topology references as we can beforehand.

This is also intended to replace the workaround that was added fix to some
of the payload leaks that were observed before $COMMIT, where we would
attempt to determine if the port was still connected to the topology before
updating payloads using drm_dp_mst_port_downstream_of_branch. This wasn't a
particularly good solution, since one of the points of still having port
and mstb validation is to avoid sending messages to newly disconnected
branches wherever possible - thus the required use of
drm_dp_mst_port_downstream_of_branch would indicate something may be wrong
with said validation.

It seems like it may have just been races and luck that made
drm_dp_mst_port_downstream_of_branch work however, as while I was trying to
figure out the true cause of this issue when removing the legacy MST code -
I discovered an important excerpt in section 2.14.2.3.3.6 of the DP 2.0
specs:

"BAD_PARAM - This reply is transmitted when a Message Transaction parameter
is in error; for example, the next port number is invalid or /no device is
connected/ to the port associated with the port number."

Sure enough - removing the calls to drm_dp_mst_port_downstream_of_branch()
and instead checking the ->ddps field of the parent port to see whether we
should release a given payload or not seems to totally fix the issue. This
does actually make sense to me, as it seems the implication is that given a
topology where an MSTB is removed, the payload for the MST parent's port
will be released automatically if that port is also marked as disconnected.
However, if there's another parent in the chain after that which is
connected - payloads must be released there with an ALLOCATE_PAYLOAD
message.

Signed-off-by: Lyude Paul <lyude@redhat.com>

TODO: Move this before the atomic rebase, and add chunks to drop all of the
downstream_port_of() uses to be replaced by this. Keep in mind that we may
need to make sure that conn_stat drops the port from the topology early
enough here.

There's another kind of situation where we could potentially race with
nonblocking modesets and MST, especially if we were to only use the locking
provided by atomic modesetting:

* Display 1 begins as enabled on DP-1 in SST mode
* Display 1 switches to MST mode, exposes one sink in MST mode
* Userspace does non-blocking modeset to disable the SST display
* Userspace does non-blocking modeset to enable the MST display with a
  different CRTC, but the SST display hasn't been fully taken down yet
* Execution order between the last two commits isn't guaranteed since they
  share no drm resources

We can fix this however, by ensuring that we always pull in the atomic
topology state whenever a connector capable of driving an MST display
performs its atomic check - and then tracking CRTC commits happening on the
SST connector in the MST topology state.

Signed-off-by: Lyude Paul <lyude@redhat.com>

Post-NV50, the only kind of encoder you'll find for DP connectors on Nvidia
GPUs are SORs (serial output resources). Because SORs have fixed
associations with their connectors, we can correctly assume that any DP
connector on a nvidia GPU will have exactly one SOR encoder routed to it
for DisplayPort.

Since we're going to need to be able to retrieve this fixed SOR DP encoder
much more often as a result of hooking up MST helpers for tracking
SST<->MST transitions in atomic states, let's simply cache this encoder in
nouveau_connector for any DP connectors on the system to avoid looking it
up each time. This isn't safe for NV50 since PIORs then come into play,
however there's no code pre-NV50 that would need to look this up anyhow -
so it's not really an issue.

Signed-off-by: Lyude Paul <lyude@redhat.com>

Currently with the MST helpers we avoid releasing payloads _and_ avoid
pulling in the MST state if there aren't any actual payload changes. While
we want to keep the first step, we need to now make sure that we're always
pulling in the MST state on all modesets that can modify payloads - even if
the resulting payloads in the atomic state are identical to the previous
ones.

This is mainly to make it so that if a CRTC is still assigned to a
connector but is set to DPMS off, the CRTC still holds it's payload
allocation in the atomic state and still appropriately pulls in the MST
state for commit tracking. Doing this allows for us to still track
bandwidth limitations in a state correctly even between DPMS changes, so
that there's no chance of a simple ->active change being rejected by the
atomic check.

Signed-off-by: Lyude Paul <lyude@redhat.com>

I'm not sure why, but at the time I originally wrote the find/release VC
slot helpers I thought we should avoid keeping modeset tracking out of the
MST helpers. In retrospect though there's no actual good reason to do
this, and the logic has ended up being identical across all the drivers
using the helpers. Also, it needs to be fixed anyway so we don't break
things when going atomic-only with MST.

So, let's just move this code into drm_dp_atomic_release_vcpi_slots() and
stop open coding it.

Signed-off-by: Lyude Paul <lyude@redhat.com>

As Daniel Vetter pointed out, if we only use the atomic modesetting locks
with MST it's technically possible for a driver with non-blocking modesets
to race when it comes to MST displays - as we make the mistake of not doing
our own CRTC commit tracking in the topology_state object.

This could potentially cause problems if something like this happens:

* User starts non-blocking commit to disable CRTC-1 on MST topology 1
* User starts non-blocking commit to enable CRTC-2 on MST topology 1

There's no guarantee here that the commit for disabling CRTC-2 will only
occur after CRTC-1 has finished, since neither commit shares a CRTC - only
the private modesetting object for MST. Keep in mind this likely isn't a
problem for blocking modesets, only non-blocking.

So, begin fixing this by keeping track of which CRTCs on a topology have
changed by keeping track of which CRTCs we release or allocate VCPI slots
on. As well, add some helpers for:

* Setting up the drm_crtc_commit structs in the ->commit_setup hook
* Waiting for any CRTC dependencies from the previous topology state

Signed-off-by: Lyude Paul <lyude@redhat.com>

Many DRM drivers feature a 'modeset' argument, which can be used to
enable/disable the entire driver (as opposed to passing nomodeset to the
kernel, which would disable modesetting globally and make it difficult to
load amdgpu afterwards). Apparently amdgpu is actually missing this
however, so let's add it!

Keep in mind that this currently just lets one enable or disable amdgpu, I
haven't bothered adding a headless mode like nouveau has - however I'm sure
someone else can add this if needed.

Signed-off-by: Lyude Paul <lyude@redhat.com>

A lot of code in amdgpu seems to sprinkle in

  if (foo != NULL)
    …

Checks pretty much all over the place, many times in locations where it's
clear foo (whatever foo may be) should never be NULL unless we've run into
a programming error. This is definitely one of those places, as
dm_mst_get_pbn_divider() should never be getting called with a NULL dc_link
pointer.

The problem with this code pattern is that many times the places I've seen
it used in amdgpu have no real error handling. This is actually quite bad,
if we try to avoid the NULL pointer and instead simply skip any code that
was expecting a valid pointer - we're already in undefined territory.
Subsequent code we execute may have expected sideaffects from the code we
skipped that are no longer present, which leads to even more unpredictable
behavior then a simple segfault. This could be silent errors or even just
another segfault somewhere else.

If we simply segfault though, that's not good either. But unlike the former
solution, no subsequent code in the kernel thread will execute - and we
will likely even get a clear backtrace from the invalid memory access. Of
course, the preferred approach is to simply handle the possibility of both
NULL and non-NULL pointers with nice error handling code. However, that's
not always desirable or even possible, and in those cases it's likely just
better to fail predictably rather than unpredictably.

This code is a nice example of that - if link is NULL, you'll return a PBN
divisor of 0. And thus, you've simply traded in your potential segfault for
a potential divide by 0 error.

Signed-off-by: Lyude Paul <lyude@redhat.com>

This function isn't too confusing if you see the comment around the
call-site for it, but if you don't then it's not at all obvious this is
meant to copy DRM's payload table over to DC's internal state structs.
Seeing this function before finding that comment definitely threw me into a
loop a few times.

So, let's rename this to make it's purpose more obvious regardless of where
in the code you are.

Signed-off-by: Lyude Paul <lyude@redhat.com>

Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.

Signed-off-by: Lyude Paul <lyude@redhat.com>

This isn't what this lock is for, drop it.

Signed-off-by: Lyude Paul <lyude@redhat.com>

Noticed this while trying to update amdgpu for the non-atomic MST removal
changes - for some reason we appear to grab mst_mgr->lock before computing
mst DSC configs. This is wrong though - mst_mgr->lock is only needed while
traversing the actual MST topology state - which is not typically something
that DRM drivers should be doing themselves anyway.

Signed-off-by: Lyude Paul <lyude@redhat.com>

We don't actually care about connection_mutex here anymore, so let's get
rid of the comment mentioning it in this function's kdocs.

Signed-off-by: Lyude Paul <lyude@redhat.com>

I noticed a rather surprising issue here while working on removing all of
the non-atomic MST code: drm_atomic_get_mst_topology_state() doesn't check
the return value of drm_atomic_get_private_obj_state() and instead just
passes it directly to to_dp_mst_topology_state(). This means that if we
hit a deadlock or something else which would return an error code pointer,
we'll likely segfault the kernel.

This is definitely another one of those fixes where I'm astonished we
somehow managed never to discover this issue until now…

Signed-off-by: Lyude Paul <lyude@redhat.com>

We already open-code this quite often, and will be iterating through
payloads even more once we've moved all of the payload tracking into the
atomic state. So, let's add a helper for doing this.

Signed-off-by: Lyude Paul <lyude@redhat.com>

VCPI is only sort of the correct term here, what we really mean is VCPI
slots as we want to differentiate VCPI slots and plain virtual channel
payload IDs (which we'll be storing in each atomic payload now). No
functional changes.

Signed-off-by: Lyude Paul <lyude@redhat.com>

In retrospect, the name I chose for this originally is confusing, as
there's a lot more info in here then just the VCPI. This really should be
called a payload. Let's make it more obvious that this is meant to be
related to the atomic state and is about payloads by renaming it to
drm_dp_mst_atomic_payload. Also, rename various variables throughout the
code that use atomic payloads.

Signed-off-by: Lyude Paul <lyude@redhat.com>

Drive-by cleanup, we don't need to validate the port references here as we
already previously went through the effort of refactoring things such that
we're guaranteed to be able to access ->mstb and ->port safely from
drm_dp_check_and_send_link_address(), since the only two places in the
codebase that drop an MST reference in such a way that it would remove it
from the topology are both protected under probe_lock.

Thanks for that, past Lyude!

Signed-off-by: Lyude Paul <lyude@redhat.com>

# Conflicts:
#	drivers/gpu/drm/i915/i915_vma.c

If i915 does not want to use huge pages there is a) no point in setting up
the private mount and b) should former fail, it is misleading to log THP
support is disabled in the caller, which does not even know if callee
tried to enable it.

Fix both by restructuring the flow in i915_gemfs_init and at the same time
note the failure to set it up in all cases.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220429100414.647857-2-tvrtko.ursulin@linux.intel.com

We have a statement from HW designers that the GPU read regression when
using 2M pages was fixed from Icelake onwards, which was also confirmed
by bencharking Eero did last year:

"""
When IOMMU is disabled, enabling THP causes following perf changes on
TGL-H (GT1):

    10-15% SynMark Batch[0-3]
    5-10% MemBW GPU texture, SynMark ShMapVsm
    3-5% SynMark TerrainFly* + Geom* + Fill* + CSCloth + Batch4
    1-3% GpuTest Triangle, SynMark TexMem* + DeferredAA + Batch[5-7]
          + few others
    -7% MemBW GPU blend

In the above 3D benchmark names, * means all the variants of tests with
the same prefix. For example "SynMark TexMem*", means both TexMem128 &
TexMem512 tests in the synthetic (Intel internal) SynMark test suite.

In the (public, but proprietary) GfxBench & GLB(enchmark) test suites,
there are both onscreen and offscreen variants of each test. Unless
explicitly stated otherwise, numbers are for both variants.

All tests are run with FullHD monitor. All tests are fullscreen except
for GLB and GpuTest ones, which are run in 1/2 screen window (GpuTest
triangle is run both in fullscreen and 1/2 screen window).
"""

Since the only regression is MemBW GPU blend, against many more gains,
it sounds it is time to enable THP on Gen11+.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/430


Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220429100414.647857-1-tvrtko.ursulin@linux.intel.com

It's the only driver using this.

v2: use BUG_ON() in vmw_bo_create() as suggested by Zack

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220329110243.6335-5-christian.koenig@amd.com

Karol Herbst authored 2 years ago and Joonas Lahtinen committed 2 years ago

i915_vma_reopen checked if the vma is closed before without taking the
lock. So multiple threads could attempt removing the vma.

Instead the lock needs to be taken before actually checking.

v2: move struct declaration

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.3+
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5732


Signed-off-by: Karol Herbst <kherbst@redhat.com>
Fixes: 155ab883 ("drm/i915: Move object close under its own lock")
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220420095720.3331609-1-kherbst@redhat.com


(cherry picked from commit 1df1c79c)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Pull parisc architecture fixes from Helge Deller:
 "Some reverts of existing patches, which were necessary because of boot
  issues due to wrong CPU clock handling and cache issues which led to
  userspace segfaults with 32bit kernels. Dave has a whole bunch of
  upcoming cache fixes which I then plan to push in the next merge
  window.

  Other than that just small updates and fixes, e.g. defconfig updates,
  spelling fixes, a clocksource fix, boot topology fixes and a fix for
  /proc/cpuinfo output to satisfy lscpu"

* tag 'for-5.18/parisc-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  Revert "parisc: Increase parisc_cache_flush_threshold setting"
  parisc: Mark cr16 clock unstable on all SMP machines
  parisc: Fix typos in comments
  parisc: Change MAX_ADDRESS to become unsigned long long
  parisc: Merge model and model name into one line in /proc/cpuinfo
  parisc: Re-enable GENERIC_CPU_DEVICES for !SMP
  parisc: Update 32- and 64-bit defconfigs
  parisc: Only list existing CPUs in cpu_possible_mask
  Revert "parisc: Fix patch code locking and flushing"
  Revert "parisc: Mark sched_clock unstable only if clocks are not syncronized"
  Revert "parisc: Mark cr16 CPU clocksource unstable on all SMP machines"

Pull powerpc fixes from Michael Ellerman:

 - Fix the DWARF CFI in our VDSO time functions, allowing gdb to
   backtrace through them correctly.

 - Fix a buffer overflow in the papr_scm driver, only triggerable by
   hypervisor input.

 - A fix in the recently added QoS handling for VAS (used for
   communicating with coprocessors).

Thanks to Alan Modra, Haren Myneni, Kajol Jain, and Segher Boessenkool.

* tag 'powerpc-5.18-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/papr_scm: Fix buffer overflow issue with CONFIG_FORTIFY_SOURCE
  powerpc/vdso: Fix incorrect CFI in gettimeofday.S
  powerpc/pseries/vas: Use QoS credits from the userspace

Pull x86 fix from Thomas Gleixner:
 "A fix and an email address update:

   - Prevent FPU state corruption.

     The condition in irq_fpu_usable() grants FPU usage when the FPU is
     not used in the kernel. That's just wrong as it does not take the
     fpregs_lock()'ed regions into account. If FPU usage happens within
     such a region from interrupt context, then the FPU state gets
     corrupted.

     That's a long standing bug, which got unearthed by the recent
     changes to the random code.

   - Josh wants to use his kernel.org email address"

* tag 'x86-urgent-2022-05-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/fpu: Prevent FPU state corruption
  MAINTAINERS: Update Josh Poimboeuf's email address

Pull timer fix from Thomas Gleixner:
 "A fix and an email address update:

   - Mark the NMI safe time accessors notrace to prevent tracer
     recursion when they are selected as trace clocks.

   - John Stultz has a new email address"

* tag 'timers-urgent-2022-05-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  timekeeping: Mark NMI safe time accessors as notrace
  MAINTAINERS: Update email address for John Stultz