linux-dev/drivers/gpu/drm/nouveau/include/nvif, branch master

drm/nouveau/disp: move DAC load detection method

2022-07-26T23:05:49Z

Signed-off-by: Ben Skeggs Reviewed-by: Lyude Paul Signed-off-by: Dave Airlie

drm/nouveau/disp: add output class

2022-07-26T23:05:49Z

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 Signed-off-by: Dave Airlie

drm/nouveau/disp: add conn method to query HPD pin status

2022-07-26T23:05:48Z

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 Reviewed-by: Lyude Paul Signed-off-by: Dave Airlie

drm/nouveau/disp: add connector class

2022-07-26T23:05:48Z

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 Reviewed-by: Lyude Paul Signed-off-by: Dave Airlie

drm/nouveau/disp: add common channel class handling

2022-07-26T23:05:48Z

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 Reviewed-by: Lyude Paul Signed-off-by: Dave Airlie

drm/nouveau/disp: add common class handling between =nv50

2022-07-26T23:05:46Z

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 Reviewed-by: Lyude Paul Signed-off-by: Dave Airlie

drm/nouveau/nvif: add wrapper for open-coded nvif_object_constructed()

2022-07-13T03:55:12Z

Signed-off-by: Ben Skeggs Reviewed-by: Lyude Paul Reviewed-by: Dave Airlie Signed-off-by: Dave Airlie

drm/nouveau: Remove the unused header file nvif/list.h

2022-02-24T21:06:11Z

The nouveau driver depends on include/linux/list.h instead of nvif/list.h, so remove the obstacle-nvif/list.h. Signed-off-by: Cai Huoqing Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20220209065322.43938-1-cai.huoqing@linux.dev

drm/nouveau/ga102-: support ttm buffer moves via copy engine

2021-10-06T09:05:45Z

We don't currently have any kind of real acceleration on Ampere GPUs, but the TTM memcpy() fallback paths aren't really designed to handle copies between different devices, such as on Optimus systems, and result in a kernel OOPS. A few options were investigated to try and fix this, but didn't work out, and likely would have resulted in a very unpleasant experience for users anyway. This commit adds just enough support for setting up a single channel connected to a copy engine, which the kernel can use to accelerate the buffer copies between devices. Userspace has no access to this incomplete channel support, but it's suitable for TTM's needs. A more complete implementation of host(fifo) for Ampere GPUs is in the works, but the required changes are far too invasive that they would be unsuitable to backport to fix this issue on current kernels. v2: fix GPFIFO length in RAMFC (reported by Karol) Signed-off-by: Ben Skeggs Cc: Lyude Paul Cc: Karol Herbst Cc: # v5.12+ Reviewed-by: Karol Herbst Tested-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20210916220406.666454-1-skeggsb@gmail.com Signed-off-by: Maarten Lankhorst

drm/nouveau: rip out nvkm_client.super

2021-08-18T09:00:15Z

No longer required now that userspace can't touch anything that might need it, and should fix DRM MM operations racing with each other, and the random hangs/crashes that come with that. Signed-off-by: Ben Skeggs Reviewed-by: Lyude Paul