UAPI Changes:
- lima: Add support for heap buffers
Cross-subsystem Changes:
Core Changes:
- Implement mode_config mode_valid for memory constrained drivers
- Bus format negociation between bridges
- Consolidate fake vblank events for drivers without vblank interrupts
- drm/bufs: dma_alloc related cleanups
- drm/dp_mst: Various fixes
- drm/print: New drm_device based print helpers
- Thomas is a drm-misc maintainer now!
Driver Changes:
- DPMS cleanups for atomic drivers
- Removal of owner field in SPI tinydrm drivers
- Removal of explicit dependency on DT for tinydrm drivers
- Conversion to YAML schemas for DT bindings
- tidss: New driver
- virtio: various reworks and fixes
- Our usual dozen or so new panels or bridges
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXkEjOgAKCRDj7w1vZxhR
xeaDAQD+1MludG4RmfQhATe4jTsPC1r2x63OF2CA0ChMGHXJyQEA8qqQ+8y1Cd/u
PZ3PpcTl4qYYHgzJ6FwW7kDPTvlaZQE=
=IJAt
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2020-02-10' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.7:
UAPI Changes:
- lima: Add support for heap buffers
Cross-subsystem Changes:
Core Changes:
- Implement mode_config mode_valid for memory constrained drivers
- Bus format negociation between bridges
- Consolidate fake vblank events for drivers without vblank interrupts
- drm/bufs: dma_alloc related cleanups
- drm/dp_mst: Various fixes
- drm/print: New drm_device based print helpers
- Thomas is a drm-misc maintainer now!
Driver Changes:
- DPMS cleanups for atomic drivers
- Removal of owner field in SPI tinydrm drivers
- Removal of explicit dependency on DT for tinydrm drivers
- Conversion to YAML schemas for DT bindings
- tidss: New driver
- virtio: various reworks and fixes
- Our usual dozen or so new panels or bridges
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200210093421.xu4sofldm6wm6xq6@gilmour.lan
The OR routing logic in NVKM does not expect to receive supervisor
interrupts until the DD has provided consistent information on the
ORs it's using and the EVO/NVD assembly state to match.
The combination of changing window ownership + core channel update
during display init triggered a situation where we'd disconnect an
OR from the pad it was meant to still be driving on some systems.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
For various complicated reasons, we need to avoid sending a core update
method during display init. Something, which we've been required to do
on GV100 and up because we've been assigning windows to heads there and
the HW is rather picky about when that's allowed.
This moves window assignment into the modesetting path at a point where
it's much safer to send our first update methods to NVDisplay.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Without relaxing this requirement, TU10x boards will fail to load without
an updated linux-firmware, and TU11x will completely fail to load because
FW isn't available yet.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This fixes an oops on TU11x GPUs where SEC2 attempts to register its falcon,
and triggers a NULL-pointer deref because ACR isn't yet supported.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The implementations for most channel types contains a map of methods to
priv registers in order to provide debugging info when a disp exception
has been raised.
This info is missing from the implementation of PIO channels as they're
rather simplistic already, however, if an exception is raised by one of
them, we'd end up triggering a NULL-pointer deref. Not ideal...
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206299
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This patch adds the support for the notification of HD-audio hotplug
via the already existing drm_audio_component framework. This allows
us more reliable hotplug notification and ELD transfer without
accessing HD-audio bus; it's more efficient, and more importantly, it
works without waking up the runtime PM.
The implementation is rather simplistic: nouveau driver provides the
get_eld ops for HD-audio, and it notifies the audio hotplug via
pin_eld_notify callback upon each nv50_audio_enable() and _disable()
call. As the HD-audio pin assignment seems corresponding to the CRTC,
the crtc->index number is passed directly as the zero-based port
number.
The bind and unbind callbacks handle the device-link so that it
assures the PM call order.
Link: https://lore.kernel.org/r/20190722143815.7339-3-tiwai@suse.de
Reviewed-by: Lyude Paul <lyude@redhat.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Since drm_global_mutex is a true global mutex across devices, we don't
want to acquire it unless absolutely necessary. For maintaining the
device local open_count, we can use atomic operations on the counter
itself, except when making the transition to/from 0. Here, we tackle the
easy portion of delaying acquiring the drm_global_mutex for the final
release by using atomic_dec_and_mutex_lock(), leaving the global
serialisation across the device opens.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Hellström (VMware) <thomas_os@shipmail.org>
Reviewed-by: Thomas Hellström <thellstrom@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200124130107.125404-1-chris@chris-wilson.co.uk
If CONFIG_IOMMU_API is n, build fails:
vers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:37:9: error: implicit declaration of function dev_iommu_fwspec_get; did you mean iommu_fwspec_free? [-Werror=implicit-function-declaration]
spec = dev_iommu_fwspec_get(device->dev);
^~~~~~~~~~~~~~~~~~~~
iommu_fwspec_free
drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:37:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
spec = dev_iommu_fwspec_get(device->dev);
^
drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:39:17: error: struct iommu_fwspec has no member named ids
u32 sid = spec->ids[0] & 0xffff;
Seletc IOMMU_API under config DRM_NOUVEAU to fix this.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drivers/gpu/drm/nouveau/dispnv04/arb.c: In function nv04_calc_arb:
drivers/gpu/drm/nouveau/dispnv04/arb.c:56:21: warning:
variable width set but not used [-Wunused-but-set-variable]
'width' is never used, so remove it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_pior_enable:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1672:28: warning:
variable nv_connector set but not used [-Wunused-but-set-variable]
commit ac2d9275f3 ("drm/nouveau/kms/nv50-: Store the
bpc we're using in nv50_head_atom") left behind this.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
gp10b doesn't have all the registers that gp102_gr_zbc wants to access,
which causes IBUS MMIO faults to occur. Avoid this by using the gp100
variants of grctx and gr_zbc.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The low-level Falcon bootstrapping callbacks are expected to return 0 on
success or a negative error code on failure. However, the implementation
on Tegra returns the ID or mask of the Falcons that were bootstrapped on
success, thus breaking the calling code, which treats this as failure.
Fix this by making sure we only return 0 or a negative error code, just
like the code for discrete GPUs does.
Fixes: 86ce2a7153 ("drm/nouveau/flcn/cmdq: move command generation to subdevs")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Another completely unused feature.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Link: https://patchwork.freedesktop.org/patch/348265/
ACR is responsible for managing the firmware for LS (Low Secure) falcons,
this was previously handled in the driver by SECBOOT.
This rewrite started from some test code that attempted to replicate the
procedure RM uses in order to debug early Turing ACR firmwares that were
provided by NVIDIA for development.
Compared with SECBOOT, the code is structured into more individual steps,
with the aim of making the process easier to follow/debug, whilst making
it possible to support newer firmware versions that may have a different
binary format or API interface.
The HS (High Secure) binary(s) are now booted earlier in device init, to
match the behaviour of RM, whereas SECBOOT would delay this until we try
to boot the first LS falcon.
There's also additional debugging features available, with the intention
of making it easier to solve issues during FW/HW bring-up in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We perform memory allocations long before we hit the code in SECBOOT that
would unlock the VPR, which could potentially result in memory allocation
within the locked region.
Run the scrubber binary right after VRAM init to ensure we don't.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When the PMU/SEC2 LS FWs have booted, they'll send a message to the host
with various information, including the configuration of message/command
queues that are available.
Move the handling for this to the relevant subdevs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This moves the code to generate commands for the ACR unit of the PMU/SEC2 LS
firmwares to those subdevs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Takes the command queue pointer directly instead of requiring a function to
lookup based on an queue type, as well as an explicit timeout value.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Functions implementing FW commands had to implement this themselves, let's
move that to common code and plumb the return code from callbacks through.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Code to interface with LS firmwares is being moved to the subdevs where it
belongs, rather than living in the common falcon code.
Arbitrary private data passed to callbacks is to allow for something other
than struct nvkm_msgqueue to be passed into the callback (like the pointer
to the subdev itself, for example), and the return code will be used where
we'd like to detect failure from synchronous messages.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Code to interface with LS firmwares is being moved to the subdevs where it
belongs, rather than living in the common falcon code.
This is an incremental step towards that goal.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Code to interface with LS firmwares is being moved to the subdevs where it
belongs, rather than living in the common falcon code.
This is an incremental step towards that goal.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
