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 <bskeggs@redhat.com>
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 <benjamin.gaignard@linaro.org>
[danvet: Fix conflict.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit a5ad0fd852.
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 <daniel.vetter@intel.com>
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 <rdunlap@infradead.org>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Martin Peres <martin.peres@free.fr>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/029a1ec5-48ac-a3ce-3106-430e0f2584bb@infradead.org
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 <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
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 <acourbot@nvidia.com>
Reviewed-by: Vince Hsu <vinceh@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
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 <treding@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
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 <jdelvare@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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 <dh.herrmann@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Acked-by: Dave Airlie <airlied@linux.ie>
Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Having nouveau builtin would still allow ACPI_VIDEO to be used as external module
if some of the deps for acpi_video have not been met, which would result in a linking
failure. Solve this by selecting all dependencies as well.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nothing terribly exciting in here probably:
- reworked thermal stuff from mupuf/I, has a chance of possibly working
well enough when we get to being able to reclock..
- driver will report mmio access faults on chipsets where it's supported
- will now sleep waiting on fences on nv84+ rather than polling
- some cleanup of the internal fencing, looking towards sli/dmabuf sync
- initial support for anx9805 dp/tmds encoder
- nv50+ display fixes related to the above, and also might fix a few
other issues
- nicer error reporting (will log process names with channel errors)
- various other random fixes
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (87 commits)
nouveau: ACPI support depends on X86 and X86_PLATFORM_DEVICES
drm/nouveau/i2c: add support for ddc/aux, and dp link training on anx9805
drm/nv50: initial kms support for off-chip TMDS/DP encoders
drm/nv50-/disp: initial supervisor support for off-chip encoders
drm/nv50-/disp: initial work towards supporting external encoders
drm/nv50-/kms: remove unnecessary wait-for-completion points
drm/nv50-/disp: move DP link training to core and train from supervisor
drm/nv50-/disp: handle supervisor tasks from workqueue
drm/nouveau/i2c: create proper chipset-specific class implementations
drm/nv50-/disp: 0x0000 is a valid udisp config value
drm/nv50/devinit: reverse the logic for running encoder init scripts
drm/nouveau/bios: store a type/mask hash in parsed dcb data
drm/nouveau/i2c: extend type to 16-bits, add lookup-by-type function
drm/nouveau/i2c: aux channels not necessarily on nvio
drm/nouveau/i2c: fix a bit of a thinko in nv_wri2cr helper functions
drm/nouveau/bios: parse external transmitter type if off-chip
drm/nouveau: store i2c port pointer directly in nouveau_encoder
drm/nouveau/i2c: handle i2c/aux mux outside of port lookup function
drm/nv50/graph: avoid touching 400724, it doesn't exist
drm/nouveau: Fix DPMS 1 on G4 Snowball, from snow white to coal black.
...
If I build nouveau on ia64, Kconfig warns:
warning: (DRM_NOUVEAU) selects ACPI_WMI which has unmet direct dependencies (X86 && X86_PLATFORM_DEVICES && ACPI)
warning: (DRM_NOUVEAU) selects MXM_WMI which has unmet direct dependencies (X86 && X86_PLATFORM_DEVICES && ACPI_WMI)
Make all the ACPI support depend on X86 and select
X86_PLATFORM_DEVICES.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Move this out of nouveau directory. As we start to add more encoder
slaves used by other drivers, it makes sense to put the Kconfig bits in
one place.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Ben H. reported that building nouveau into the kernel and power supply
as a module was broken.
Just have nouveau select it, like radeon does.
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix build errors when CONFIG_ACPI is enabled but MXM_WMI is not enabled
by selecting both MXM_WMI and ACPI_WMI (the latter just for kconfig
dependencies):
nouveau_acpi.c:(.text+0x2400c8): undefined reference to `mxm_wmi_call_mxmx'
nouveau_acpi.c:(.text+0x2400cf): undefined reference to `mxm_wmi_call_mxds'
nouveau_acpi.c:(.text+0x2400fe): undefined reference to `mxm_wmi_call_mxmx'
nouveau_acpi.c:(.text+0x2402ba): undefined reference to `mxm_wmi_supported
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this hooks up nouveau to the MXM mux switching method.
With this in place I can switch the LVDS MUX on my T410s,
I expect we need a bit more work for other laptops.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
is used to configure any non-standard kernel with a much larger scope than
only small devices.
This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
references to the option throughout the kernel. A new CONFIG_EMBEDDED
option is added that automatically selects CONFIG_EXPERT when enabled and
can be used in the future to isolate options that should only be
considered for embedded systems (RISC architectures, SLOB, etc).
Calling the option "EXPERT" more accurately represents its intention: only
expert users who understand the impact of the configuration changes they
are making should enable it.
Reviewed-by: Ingo Molnar <mingo@elte.hu>
Acked-by: David Woodhouse <david.woodhouse@intel.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Greg KH <gregkh@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Robin Holt <holt@sgi.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
CONFIG_ACPI_VIDEO depends on more than just CONFIG_ACPI, so add those
dependencies to the Kconfig select condition. The case where some
dependencies fail to be satisfied should be handled correctly, because
in that case the ACPI_VIDEO symbols we use are converted into
static-inline stubs.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Build breakage:
drivers/built-in.o: In function `nouveau_acpi_edid':
(.text+0x13404e): undefined reference to `acpi_video_get_edid'
make: *** [.tmp_vmlinux1] Error 1
Introduced by:
a6ed76d7ff is the first bad commit
commit a6ed76d7ff
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Mon Jul 12 15:33:07 2010 +1000
drm/nouveau: support fetching LVDS EDID from ACPI
Based on a patch from Matthew Garrett.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Acked-by: Matthew Garrett <mjg@redhat.com>
It doesn't seem to revert cleanly, but the problem lies in these
two config entries:
CONFIG_ACPI=y
CONFIG_ACPI_VIDEO=m
Adding a select for ACPI_VIDEO appears to be the best solution, and
is comparable to what is done in DRM_I915. Builds, boots, and appears to
work correctly.
Signed-off-by: Philip J. Turmel <philip@turmel.org>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
sil164 transmitters are used for DVI outputs on Intel/nvidia and ATI setups.
So far only nouveau can use this driver.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Tested-by: Patrice Mandin <patmandin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now that highlevel DRM no longer requires PCI, we can move the requirement
into the lowlevel drivers.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This partially reverts e4b41066, as this driver is intended to be
useful with any KMS driver for suitable hardware. The missing build
dependency that commit workarounded was DRM_KMS_HELPER.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
The ch7006 driver could be built even when nouveau was not enabled,
but the build fails in that case, so make it depend on DRM_NOUVEUA.
Also make the I2c encoder/helper chips menu depend on I2C (no build
error, just visual inspection).
ERROR: "drm_helper_probe_single_connector_modes" [drivers/gpu/drm/i2c/ch7006.ko] undefined!
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA.
This driver is a KMS-based driver and requires a compatible nouveau
userspace libdrm and nouveau X.org driver.
This driver requires firmware files not available in this kernel tree,
interested parties can find them via the nouveau project git archive.
This driver is reverse engineered, and is in no way supported by nVidia.
Support for nearly the complete range of nvidia hw from nv04->g80 (nv50)
is available, and the kms driver should support driving nearly all
output types (displayport is under development still) along with supporting
suspend/resume.
This work is all from the upstream nouveau project found at
nouveau.freedesktop.org.
The original authors list from nouveau git tree is:
Anssi Hannula <anssi.hannula@iki.fi>
Ben Skeggs <bskeggs@redhat.com>
Francisco Jerez <currojerez@riseup.net>
Maarten Maathuis <madman2003@gmail.com>
Marcin Kościelnicki <koriakin@0x04.net>
Matthew Garrett <mjg@redhat.com>
Matt Parnell <mparnell@gmail.com>
Patrice Mandin <patmandin@gmail.com>
Pekka Paalanen <pq@iki.fi>
Xavier Chantry <shiningxc@gmail.com>
along with project founder Stephane Marchesin <marchesin@icps.u-strasbg.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
