- 07 Nov, 2016 39 commits
-
-
Ben Skeggs authored
This commit separates the calculation of EVO state from the commit, in order to make the same code useful for atomic modesetting. The legacy interfaces have been wrapped on top of them. As of this commit, we're no longer bothering to point the core surface at a valid framebuffer. Prior to this, we'd initially point the core channel to the framebuffer passed in a mode_set()/mode_set_base(), and then use the base channel for any page-flip updates, leaving the core channel pointing at stale information. The important thing here is to configure the core surface parameters in such a way that EVO's error checking is satisfied. TL;DR: The situation isn't too much different to before. There may be brief periods of times during modesets where the (garbage) core surface will be showing. This issue will be resolved once support for atomic commits has been implemented and we're able to interlock the updates that involve multiple channels. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This commit separates the calculation of EVO state from the commit, in order to make the same code useful for atomic modesetting. The legacy interfaces have been wrapped on top of them. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Will be useful in debugging the transition to atomic. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Sometimes we load with a sink already in MST mode. If, however, we can't or don't want to use MST, we need to be able to switch it back to SST. This commit instantiates a stub topology manager for any output path that we believe (the detection of this could use some improvement) has support for MST, and adds the connector detect() logic for detecting sink support and switching between modes. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This is different from the equivilant functions in the atomic helpers in that we fully disable the pipe instead of just setting it to inactive. We do this (primarily) to ensure the framebuffer cleanup paths are hit, allowing buffers to be un-pinned from memory so they can be evicted to system memory and not lose their contents while suspended. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
These will also be used by MST connectors. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This commit implements the atomic property hooks for a connector, and wraps the legacy interface handling on top of those. For the moment, a full modeset will be done after any property change in order to ease subsequent changes. The optimised behaviour will be restored for Tesla and later (earlier boards always do full modesets) once atomic commits are implemented. Some functions are put under the "nouveau_conn" namespace now, rather than "nouveau_connector", to distinguish functions that will work for (upcoming) MST connectors too. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This will ensure we have some kind of initial atomic state for all objects after initialisation. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
nouveau_display_fini() is responsible for quiescing the hardware, so this is where such actions belong. More than that, nouveau_display_fini() switches off the receiving of sink irqs, which MST will require while shutting down an active head. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This primarily existed to ensure the DP link got retrained, and is now unnecessary as that's handled by NVKM already. For anything beyond that, we send an event to userspace and let it decide on an appropriate action to take. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Transitional step towards properly refcounting the fbcon fb. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
No need to store the pointer ourselves when it's already present in the base struct. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
There haven't been any callers from an atomic context for a while now, so let's remove the extra complexity. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Christophe JAILLET authored
'iommu_domain_alloc()' returns NULL in case of error, not an error pointer. So test it accordingly. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
gm20b's FB has the same capabilities as gm200, minus the ability to allocate RAM. Create a device that reflects this instead of re-using the gk20a device which may be incorrect. Signed-off-by:
Alexandre Courbot <acourbot@nvidia.com> Reviewed-By:
Karol Herbst <karolherbst@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
gk20a's FB is not special compared to other Kepler chips, besides the fact it does not have VRAM. Use the regular gf100 hooks instead of the incomplete versions we rewrote. Signed-off-by:
Alexandre Courbot <acourbot@nvidia.com> Reviewed-By:
Karol Herbst <karolherbst@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
The gf100 constructor should be called, otherwise we will allocate a smaller object than expected. This was without effect so far because gk20a did not allocate a page, but with gf100's page allocation moved to the oneinit() hook this problem has become apparent. Signed-off-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
The reset hook of pmu_func is never called, and gt215 was the only chip to implement. Remove this dead code. Signed-off-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Lucas Stach authored
There is no reason to not free the notify data if the NTFY_DEL ioctl failed. As nvif_notify_fini() is also called from the cleanup path of nvif_notify_init(), the notifier may not have been successfully created at that point. But it should also be the right thing to just free the data in the regular fini calls, as there is nothing much we can do if the ioctl fails, so better not leak memory. Signed-off-by:
Lucas Stach <dev@lynxeye.de> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Lucas Stach authored
uevent based fences hold a reference to the fence context, just like the legacy ones. So they need to drop this reference in the same way. Signed-off-by:
Lucas Stach <dev@lynxeye.de> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Arnd Bergmann authored
gcc-4.9 notices that the validate_init() function returns unintialized data when called with a zero 'nr_buffers' argument, when called with the -Wmaybe-uninitialized flag: drivers/gpu/drm/nouveau/nouveau_gem.c: In function ‘validate_init.isra.6’: drivers/gpu/drm/nouveau/nouveau_gem.c:457:5: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized] However, the only caller of this function always passes a nonzero argument, and gcc-6 is clever enough to take this into account and not warn about it any more. Adding an explicit initialization to -EINVAL here is correct even if the caller changed, and it avoids the warning on gcc-4.9 as well. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-By:
Karol Herbst <karolherbst@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Baoyou Xie authored
We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:29:1: warning: no previous prototype for 'nvbios_fan_table' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:56:1: warning: no previous prototype for 'nvbios_fan_entry' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:184:1: warning: no previous prototype for 'gt215_clk_info' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:99:1: warning: no previous prototype for 'gt215_link_train_calc' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:153:1: warning: no previous prototype for 'gt215_link_train' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:271:1: warning: no previous prototype for 'gt215_link_train_init' [-Wmissing-prototypes] .... In fact, both functions are only used in the file in which they are declared and don't need a declaration, but can be made static. So this patch marks these functions with 'static'. Signed-off-by:
Baoyou Xie <baoyou.xie@linaro.org> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Baoyou Xie authored
We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c:69:1: warning: no previous prototype for 'nvkm_sddr3_calc' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c:60:1: warning: no previous prototype for 'nvkm_sddr2_calc' [-Wmissing-prototypes] .... In fact, these functions are declared in drivers/gpu/drm/nouveau/include/nvkm/core/firmware.h drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.h drivers/gpu/drm/nouveau/nvkm/subdev/volt/priv.h drivers/gpu/drm/nouveau/nvkm/engine/gr/nv50.h drivers/gpu/drm/nouveau/dispnv04/disp.h. So this patch adds missing header dependencies. Signed-off-by:
Baoyou Xie <baoyou.xie@linaro.org> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
DPAUX registers moved on Kepler, these chipsets were still using the Fermi implementation for some reason. This fixes detection of hotplug/sink IRQs on DP connectors. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
Ben Skeggs authored
This fixes (works around?) link training failures seen on (at least) the Lenovo P50's internal panel. It's also an important fix on the same system for MST support on the dock. Sometimes, right after receiving an IRQ from the sink, there's an error bit (SINKSTAT_ERR) set in the DPAUX registers before we've even attempted a transaction. v2. Fixed regression on passive DP->DVI adapters. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
- 06 Nov, 2016 1 commit
-
-
Dave Airlie authored
Linux 4.9-rc4 This is needed for nouveau development.
-