Re-uses the implementation's accessor functions rather than requiring
and init/fini implementation for each chipset.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There's really not a great deal this time due to me spending most of this window on Maxwell. But, here's the random bits and pieces that's currently queued.
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (25 commits)
drm/gk208/gr: add missing registers to grctx init
drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.
drm/nv50-/mc: fix kms pageflip events by reordering irq handling order.
drm/nouveau/disp/nv04-nv40: abort scanoutpos query on vga analog.
drm/nv50-/kms: wait for enough ring space in crtc_prepare()
drm/nouveau/disp/dp: support training pattern 3
drm/nouveau/disp/dp: support aux read interval during link training
drm/gk104/gpio: fix incorrect interrupt register usage
drm/nouveau/core: punt all object state change messages to trace level
drm/nouveau/clk: allow end-user reclocking for nv40, nvaa, and nve0 clock types
drm/nouveau/fb: default NvMemExec to on, turning it off is used for debugging only
drm/nouveau/bios: fix a potential NULL deref in the PROM shadowing function
drm/nouveau/i2c: bump the i2c delay for the adt7473
drm/nouveau/therm/fan/tach: default to 2 pulses per revolution
drm/nvf0/device: enable video decoding engines on gk110/gk208
drm/nvf1/device: add support for 0xf1 (gk110b)
drm/nouveau/device: support for probing GK20A
drm/nouveau/graph: add GK20A support
drm/nouveau/graph: pad firmware code at load time
drm/nouveau/graph: enable when using external fw
...
This fixes hangs on GK208 which happen instantaneously on trying to use a
geometry shader.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org # v3.14+
Cards with nv04 display engine can't reliably use vblank
counts and timestamps computed via drm_handle_vblank(), as
the function gets invoked after sending the pageflip events.
Fix this by defaulting to the old crtcid = -1 fallback path
on <= NV-50 cards, and only using the precise path on NV-50
and later.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: <stable@vger.kernel.org> # 3.13+
Whenever a single nouveau_mc_intr() main gpu irq-handler invocation was
responsible for calling both, the vblank-irq handler (display engine irq)
and kms-pageflip completion handler (from fifo irq), the order of
invocation was wrong. nouveau_finish_flip() was called before
drm_handle_vblank() for the vblank of pageflip completion, so the
emitted pageflip event contained stale vblank count and timestamp
from previous vblank. This caused failure in userspace to timestamp
properly.
Reorder order of invocation of engine irq handlers: Put
NVDEV_ENGINE_DISP always on top, and thereby before NVDEV_ENGINE_FIFO,
so that drm_handle_vblank() gets called to update vblank timestamps
and count before potential pageflip events make use of that
information.
This works on nv-50 and later, where kms-pageflip completion triggers
an irq either after a separate vblank irq, or both pageflip and vblank
trigger one common irq invocation, but never before vblank irqs.
v2 (Ben):
- removed mods for nv04-nv40, it doesn't help there anyway
- this is considered a hack, and a better solution should be found
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: <stable@vger.kernel.org> # 3.13+
nv04_disp_scanoutpos() must abort to trigger simple timestamping
fallback if vtotal/htotal regs return zero. This happens if the
output isn't a digital output, but a vga analog output, as the
regs don't get initialized in that case.
Fixes timestamping failure on nv-40 and earlier with vga output.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: <stable@vger.kernel.org> # 3.14+
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Some adt7473 can't manage the 20µs delay we use for the bitbanging, bumping
it to 40µs seem to do the trick.
Signed-off-by: Martin Peres <martin.peres@free.fr>
Tested-by: Marcel Dopita <mdop@seznam.cz>
I spent some time this weekend trying to find in the vbios the number of
pulses per revolutions in the vbios but couldn't find it. It would seem
all my cards have 2 pulses per revolution so let's stick to that until
further notice.
Thermal table's id 0x48 may indicate this information but it would seem
that changing the value results in the blob power or clock gating the
RPM counter... We should ask NVIDIA about that, should be trivial-enough
for them to answer.
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Set the correct subdev/engine classes when GK20A (0xea) is probed.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a GR device for GK20A based on NVE4, with the correct classes
definitions (GK20A's 3D class is 0xa297).
Most of the NVE4 code can be used on GK20A, so make relevant bits of
NVE4 available to other chips as well.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Pad the microcode to a multiple of 0x40 words, otherwise firmware will
fail to run from non-prepadded firmware files.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nvc0_graph_ctor() would only let the graphics engine be enabled if its
oclass has a proper microcode linked to it. This prevents GR from being
enabled at all on chips that rely exclusively on external firmware, even
though such a use-case is valid.
Relax the conditions enabling the GR engine to also include the case
where an external firmware has also been loaded.
Also switch to external firmware if the graph class has no microcode
linked to it.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GK20A's FIFO is compatible with NVE0, but only features 128 channels and
1 runlist.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a simple FB device for GK20A, as well as a RAM implementation
suitable for chips that use system memory as video RAM.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add support for initializing the priv ring of GK20A. This is done by the
BIOS on desktop GPUs, but needs to be done by hand on Tegra.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Adapt the NVC0 BAR driver to make it able to support chips that do not
expose a BAR3. When this happens, BAR1 is then used for USERD mapping
and the BAR alloc() functions is disabled, making GPU objects unable
to rely on BAR for data access and falling back to PRAMIN.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Some chips that use system memory exclusively (e.g. GK20A) do not
expose 2 BAR regions. For them only BAR1 exists, and it should be used
for USERD mapping. Do not map BAR3 if its resource does not exist.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used
in a few places. I suspect its usage has been spread by copy & paste
rather than anything else.
Let's just remove it for plain ARRAY_SIZE().
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
One small step after another, the never-ending crusade towards better
code continues.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Merge drm-fixes into drm-next.
Both i915 and radeon need this done for later patches.
Conflicts:
drivers/gpu/drm/drm_crtc_helper.c
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/i915_gem_execbuffer.c
drivers/gpu/drm/i915/i915_gem_gtt.c
* acpi-video:
ACPI / video: Add 4 new models to the use_native_backlight DMI list
ACPI / video: Add use native backlight quirk for the ThinkPad W530
ACPI / video: Unregister the backlight device if a raw one shows up later
backlight: Add backlight device (un)registration notification
nouveau: Don't check acpi_video_backlight_support() before registering backlight
acer-wmi: Add Aspire 5741 to video_vendor_dmi_table
acer-wmi: Switch to acpi_video_unregister_backlight
ACPI / video: Add an acpi_video_unregister_backlight function
ACPI / video: Don't register acpi_video_resume notifier without backlight devices
ACPI / video: change acpi-video brightness_switch_enabled default to 0
acpi_video_backlight_support() is supposed to be called by other (vendor
specific) firmware backlight controls, not by native / raw backlight controls
like nv_backlight.
Userspace will normally prefer firmware interfaces over raw interfaces, so
if acpi_video backlight support is present it will use that even if
nv_backlight is registered as well.
Except when video.use_native_backlight is present on the kernel cmdline
(or enabled through a dmi based quirk). As the name indicates the goal here
is to make only the raw interface available to userspace so that it will use
that (it only does this when it sees a win8 compliant bios).
This is done by:
1) Not registering any acpi_video# backlight devices; and
2) Making acpi_video_backlight_support() return true so that other firmware
drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
own vender specific interfaces.
Currently nouveau breaks this setup, as when acpi_video_backlight_support()
returns true, it does not register itself, resulting in no backlight control
at all.
This is esp. going to be a problem with 3.16 which will default to
video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
will get no backlight control at all.
This also likely explains why the previous attempt to make
video.use_native_backlight=1 the default was not a success, as without this
patch having a default of video.use_native_backlight=1 will cause regressions.
Note this effectively reverts commit 5bead799d3 (drm/nouveau: don't
expose backlight control when available through ACPI).
References: https://bugzilla.redhat.com/show_bug.cgi?id=1093171
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
fixes nasty panel bleeding bug.
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/gf119-/disp: fix nasty bug which can clobber SOR0's clock setup
drm/nvd9/therm: handle another kind of PWM fan
Fixes a LVDS bleed issue on Lenovo W530 that can occur under a
number of circumstances.
Cc: <stable@vger.kernel.org > # v3.9+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
