kernel/drivers/gpu/drm/nouveau/Kconfig, branch linux-4.17.y

drm/nouveau/mmu: implement new vmm backend

2017-11-02T03:32:27Z

This is the common code to support a rework of the VMM backends. It adds support for more than 2 levels of page table nesting, which is required to be able to support GP100's MMU layout. Sparse mappings (that don't cause MMU faults when accessed) are now supported, where the backend provides it. Dual-PT handling had to become more sophisticated to support sparse, but this also allows us to support an optimisation the MMU provides on GK104 and newer. Certain operations can now be combined into a single page tree walk to avoid some overhead, but also enables optimsations like skipping PTE unmap writes when the PT will be destroyed anyway. The old backend has been hacked up to forward requests onto the new backend, if present, so that it's possible to bisect between issues in the backend changes vs the upcoming frontend changes. Until the new frontend has been merged, new backends will leak BAR2 page tables on module unload. This is expected, and it's not worth the effort of hacking around this as it doesn't effect runtime. Signed-off-by: Ben Skeggs

drm: fix compilations issues introduced by "drm: allow to use mmuless SoC"

2017-01-09T10:30:30Z

Removing MMU configuration flag from DRM make few automatic build failed when they answer yes to all flags. Add asm/vga.h file on Blackfin architecture to not broke compilation. Signed-off-by: Benjamin Gaignard Fixes: 62a0d98a188c ("drm: allow to use mmuless SoC") Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483789151-6603-1-git-send-email-benjamin.gaignard@linaro.org

drm: compile drm_vm.c only when needed

2017-01-06T10:03:07Z

drm_vm.c functions are only need for DRM_LEGACY and DRM_NOUVEAU. Use a new DRM_VM to define when drm_vm.c in needed. stub drm_legacy_vma_flush() to avoid compilation issues version 4: - a "config DRM_VM" in Kconfig Signed-off-by: Benjamin Gaignard [danvet: Fix conflict.] Signed-off-by: Daniel Vetter

Revert "drm: nouveau: fix build when LEDS_CLASS=m"

2017-01-05T07:59:17Z

This reverts commit a5ad0fd8524e5144512a5c25eda5a5d6fd55fda8. It results in kconfing complaining about recursive depencies: drivers/usb/Kconfig:39:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/input/mouse/Kconfig:187: symbol MOUSE_APPLETOUCH depends on INPUT For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/input/Kconfig:8: symbol INPUT is selected by VT For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/tty/Kconfig:12: symbol VT is selected by FB_STI For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:678: symbol FB_STI depends on FB For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/Kconfig:128: symbol DRM_KMS_CMA_HELPER is selected by DRM_HDLCD For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/arm/Kconfig:6: symbol DRM_HDLCD depends on COMMON_CLK For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/clk/Kconfig:9: symbol COMMON_CLK is selected by X86_INTEL_QUARK For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" arch/x86/Kconfig:554: symbol X86_INTEL_QUARK depends on X86_PLATFORM_DEVICES For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/platform/x86/Kconfig:5: symbol X86_PLATFORM_DEVICES is selected by DRM_NOUVEAU For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/nouveau/Kconfig:1: symbol DRM_NOUVEAU depends on LEDS_CLASS For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/leds/Kconfig:16: symbol LEDS_CLASS is selected by ATH9K_HTC For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on USB warning: (DRM_NOUVEAU && DRM_I915 && DRM_GMA500) selects ACPI_VIDEO which has unmet direct dependencies (ACPI && X86 && +BACKLIGHT_CLASS_DEVICE && INPUT) And there's apparently a better patch available already. Signed-off-by: Daniel Vetter

drm: nouveau: fix build when LEDS_CLASS=m

2017-01-04T08:55:57Z

Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same kconfig value as LEDS_CLASS. drivers/built-in.o: In function `nouveau_do_suspend': nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' drivers/built-in.o: In function `nouveau_do_resume': nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' drivers/built-in.o: In function `nouveau_drm_unload': nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' drivers/built-in.o: In function `nouveau_drm_load': nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' BTW, this line in Kbuild: nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. Signed-off-by: Randy Dunlap Reported-by: kbuild test robot Cc: Martin Peres Cc: Ben Skeggs Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/029a1ec5-48ac-a3ce-3106-430e0f2584bb@infradead.org

drm/nouveau: make fbdev support really optional

2016-07-15T14:28:40Z

Currently enabling Nouveau DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by: Tobias Jakobi Signed-off-by: Sean Paul

drm/nouveau: merge nouveau_platform.ko into nouveau.ko

2015-01-22T02:15:09Z

Having the two modules separated causes various unneeded complications, including having to export symbols accessed between the modules. Make things simpler by compiling platform device support into nouveau.ko. Platform device support remains optional and is only compiled on Tegra. Signed-off-by: Alexandre Courbot Reviewed-by: Vince Hsu Signed-off-by: Ben Skeggs

drm/nouveau: support for probing platform devices

2014-08-09T19:11:10Z

Add a platform driver for Nouveau devices declared using the device tree or platform data. This driver currently supports GK20A on Tegra platforms and is only compiled for these platforms if Nouveau is enabled. Nouveau will probe the chip type itself using the BOOT0 register, so all this driver really needs to do is to make sure the module is powered and its clocks active before calling nouveau_drm_platform_probe(). Heavily based on work done by Thierry Reding. Signed-off-by: Thierry Reding Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs

ACPI / gpu / drm: Stop selecting VIDEO_OUTPUT_CONTROL

2014-03-20T01:37:22Z

ACPI_VIDEO no longer depends on VIDEO_OUTPUT_CONTROL, so drivers which want to select ACPI_VIDEO no longer have to select VIDEO_OUTPUT_CONTROL. Signed-off-by: Jean Delvare Acked-by: Daniel Vetter Signed-off-by: Rafael J. Wysocki

drm: Add separate Kconfig option for fbdev helpers

2013-10-11T21:36:58Z

For drivers which might want to disable fbdev legacy support. Select the new option in all drivers for now, so this shouldn't result in any change. Drivers need some work anyway to make fbdev support optional (if they have it implemented, that is), so the recommended way to expose this is by adding per-driver options. At least as long as most drivers don't support disabling the fbdev support. v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm driver can already take advantage of this, which allows us to build msm without any fbdev depencies in the kernel! v3: Move the MODULE_* stuff from the fbdev helper file to drm_crtc_helper.c. Cc: David Herrmann Cc: Rob Clark Reviewed-by: Rob Clark Acked-by: Dave Airlie Reviewed-by: Chon Ming Lee Signed-off-by: Daniel Vetter