Nathan Schulte [Tue, 15 Mar 2016 15:14:05 +0000 (10:14 -0500)]
drm/i915: add module param "enable_dp_mst"
Adds an (unsafe; auto-kernel-tainting) boolean module parameter to the i915
drm driver: "enable_dp_mst", which is enabled by default. Disabling the
parameter forces newly connected DisplayPort sinks to report as not
supporting multi-stream transport (MST), thus "forcing" the use of
single-stream transport (SST).
v2: rename parameter to conform to style
v3: add signoff
But that didn't fully work so I cleaned it up with:
for f in *.[hc]; do sed -i -e s/I915_NUM_RINGS/I915_NUM_ENGINES/ $f; done
for f in *.[hc]; do sed -i -e s/i915_gem_request_get_ring/i915_gem_request_get_engine/ $f; done
for f in *.[hc]; do sed -i -e s/intel_ring_flag/intel_engine_flag/ $f; done
for f in *.[hc]; do sed -i -e s/intel_ring_idle/intel_engine_idle/ $f; done
for f in *.[hc]; do sed -i -e s/init_ring_lists/init_engine_lists/ $f; done
for f in *.[hc]; do sed -i -e s/i915_gem_reset_ring_cleanup/i915_gem_reset_engine_cleanup/ $f; done
for f in *.[hc]; do sed -i -e s/i915_gem_reset_ring_status/i915_gem_reset_engine_status/ $f; done
v2: Rebase.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Imre Deak [Mon, 14 Mar 2016 17:55:34 +0000 (19:55 +0200)]
drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs
After the commit below the Broxton PLL IDs had an off-by-one error, so
fix this up. Also add a missing brace at intel_shared_dpll_init(), it
happened to compile only due to the way the IS_BROXTON macro is defined.
v2:
- remove debugging left-over
Fixes: a3c988ea068c ("drm/i915: Make SKL/KBL DPLL0 managed by the shared dpll code") CC: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> CC: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457978134-12362-1-git-send-email-imre.deak@intel.com
drm/i915: Nuke fbc members from intel_crtc->atomic, v4.
Whenever there's an update to the primary plane,
fbc_pre_update and fbc_post_update are called. Kill off
intel_crtc->atomic.update_fbc and now that intel_crtc->atomic
is empty, kill it off too.
Changes since v1:
- Add a intel_fbc_supports_rotation helper.
Changes since v2:
- Remove intel_fbc_supports_rotation_helper.
- Remove unrelated changes.
Changes since v3:
- Rebase
drm/i915: Remove some post-commit members from intel_crtc->atomic, v3.
fb_bits is useful to have in the crtc_state for cs flips when
the code is updated to use intel_frontbuffer_flip_prepare/complete.
So calculate it in advance and move it to crtc_state. The other stuff
can be calculated in post_plane_update, and aren't useful elsewhere.
Changes since v1:
- Changing wording, remove comment about loop.
Changes since v2:
- Rebase.
Daniel Vetter [Wed, 16 Mar 2016 07:11:09 +0000 (08:11 +0100)]
Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued
Backmerge because:
- Maarten needs latest atomic patches from drm-misc.
- Lionel needs the color manager core patch from drm-misc.
- Ander extracted intel_dpll_mgr.c, we need a backmerge to avoid git
losing track of things too often (right now it seems ok due to
cherry-picks).
- Tvrtko needs a stable baseline to apply some large-scale renaming
patches to i915 GEM code.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
gcc-6 warns about code in the nouveau driver that is obviously silly:
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c: In function 'nv40_perfctr_next':
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c:62:19: warning: self-comparison always evaluats to false [-Wtautological-compare]
if (pm->sequence != pm->sequence) {
The behavior was accidentally introduced in a patch described as "This is
purely preparation for upcoming commits, there should be no code changes here.".
As far as I can tell, that was true for the rest of that patch except for
this one function, which has been changed to a NOP.
This patch restores the original behavior.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 8c1aeaa13954 ("drm/nouveau/pm: cosmetic changes") Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Wed, 16 Mar 2016 01:09:00 +0000 (11:09 +1000)]
Merge tag 'drm-amdkfd-next-fixes-2016-03-15' of git://people.freedesktop.org/~gabbayo/linux into drm-next
* tag 'drm-amdkfd-next-fixes-2016-03-15' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: uninitialized variable in dbgdev_wave_control_set_registers()
Tomi Valkeinen [Tue, 15 Mar 2016 12:55:53 +0000 (14:55 +0200)]
drm/omap: fix panel/encoder probes
The recent changes which removed platform data support from panels &
encoders had a few mistakes, causing probes of DVI connector and DSI
command mode panels to fail every time due to missing '!'. Fix the
if()s.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Mon, 14 Mar 2016 23:49:19 +0000 (09:49 +1000)]
Merge tag 'drm-vc4-next-2016-03-14' of github.com:anholt/linux into drm-next
This pull request covers what's left for 4.6. Notably, it includes a
significant 3D performance improvement and a fix to HDMI hotplug
detection for the Pi2/3.
* tag 'drm-vc4-next-2016-03-14' of github.com:anholt/linux:
drm/vc4: Recognize a more specific compatible string for V3D.
dt-bindings: Add binding docs for V3D.
drm/vc4: Return -EFAULT on copy_from_user() failure
drm/vc4: Respect GPIO_ACTIVE_LOW on HDMI HPD if set in the devicetree.
drm/vc4: Let gpiolib know that we're OK with sleeping for HPD.
drm/vc4: improve throughput by pipelining binning and rendering jobs
Eric Anholt [Fri, 4 Mar 2016 20:32:07 +0000 (12:32 -0800)]
drm/vc4: Recognize a more specific compatible string for V3D.
The Raspberry Pi Foundation's firmware updates are shipping device
trees using the old string, so we'll keep recognizing that as this rev
of V3D. Still, we should use a more specific name in the upstream DT
to clarify which board is being supported, in case we do other revs of
V3D in the future.
Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Dave Airlie [Mon, 14 Mar 2016 00:49:40 +0000 (10:49 +1000)]
Merge branch 'linux-4.6' of git://github.com/skeggsb/linux into drm-next
- GM20x secure boot support (hence, acceleration, finally \o/)
- GM200 support
- GM20B clock driver
- Support for power sensors on some GPUs
- Various other fixes all over the place
* 'linux-4.6' of git://github.com/skeggsb/linux: (95 commits)
drm/nouveau/clk/gm20b: add basic driver
drm/nouveau/clk/gk20a: share reusable structures/functions
drm/nouveau/clk/gk20a: set lowest frequency during init()
drm/nouveau/clk/gk20a: split gk20a_clk_new()
drm/nouveau/clk/gk20a: abstract pl_to_div
drm/nouveau/clk/gk20a: put mnp values into their own struct
drm/nouveau/clk/gk20a: emit parent rate as debug message
drm/nouveau/clk/gk20a: only restore divider to 1:1 if needed
drm/nouveau/clk/gk20a: only compute n_lo if needed
drm/nouveau/clk/gk20a: fix VCO bit mask
drm/nouveau/clk/gk20a: rename enable/disable functions
drm/nouveau/clk/gk20a: reorganize variables in gk20a_pllg_calc_mnp()
drm/nouveau/clk/gk20a: convert parameters to Khz
drm/nouveau/volt: add GM20B driver
drm/nouveau/volt/gk20a: split constructor
drm/nouveau/volt/gk20a: share reusable members & functions
drm/nouveau/ce/gm107: expose MaxwellDmaCopyA
drm/nouveau/fifo/gm107: KeplerChannelGpfifoB, and 2048 channels
drm/nouveau/fifo/gk110: expose KeplerChannelGpfifoB
drm/nouveau/fifo/gk104: submit NOP after all PBDMA_INTR_0, not just DEVICE
...
drm/nouveau/clk/gk20a: only restore divider to 1:1 if needed
Only restore the 1:1 divider if it is not set already. Also use the
proper masks for this operation and add a second write as done in the
Android code.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fix the mask specified to switch to VCO mode was given as an (incorrect)
immediate value. Although the side-effect happens to be the same, this
is clearly incorrect.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
gk20a_pllg_disable() is only used in the context of gk20a_clk_fini().
Move its body there and rename _gk20a_pllg_enable() and
_gk20a_pllg_disable() to non-underscored versions.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This class supports a WFI method (0x0078) that's not present on the
KeplerChannelGpfifoA class.
The binary driver exposes both classes on these GPUs for some reason,
though there doesn't appear to be any difference in the setup that's
done for each (ie. even if you allocate GpfifoA, the WFI method will
still work).
We shall just expose GpfifoB, as I don't see a good reason to report
the presence of both.
Ilia Mirkin [Sun, 6 Mar 2016 21:06:06 +0000 (16:06 -0500)]
drm/nouveau/core: use vzalloc for allocating ramht
Most calls to nvkm_ramht_new use 0x8000 as the size. This results in a
fairly sizeable chunk of memory to be allocated, which may not be
available with kzalloc. Since this is done fairly rarely (once per
channel), use vzalloc instead.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
A channel may still be processed by the PBDMA even after removal, unless
it is properly kicked. Some chips are more sensible to this than others,
with GM20B triggering the issue very easily (the PBDMA will try to fetch
methods from the previously-removed channel after a new one is added).
Make sure this cannot happen by kicking the channel right after it is
disabled, and before the new runlist is submitted.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/instmem/gk20a: add write barrier when releasing DMA object
When using the DMA-API for instmem, we may obtain a write-combined
mapping. For such cases, add a write barrier in
gk20a_instobj_release_dma() to make sure that all writes have reached
memory at this time.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Registration of the hwmon device will fail on non-PCI systems since
dev->pdev is NULL in that case. Use the more generic drm_device::dev
member that points to the same and is always set no matter the platform.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The DMA API has different semantics on different architectures.
Currently on arm64, it can only provide memory from a small pool which
dries up quickly if we attempt to allocate big buffers from it.
Do not consider that option when running on non-x86, since regular TTM
buffers are the (current) best-fit for ARM platforms.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/fifo/gk104: take runlist target into account
Bits 28:29 of RUNLIST_BASE specify the memory target of the runlist. Set
it to 0x3 (SYS_MEM_NONCOHERENT) if the runlist object resides in system
memory.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/fifo/gf100: take runlist target into account
Bits 28:29 of RUNLIST_BASE specify the memory target of the runlist. Set
it to 0x3 (SYS_MEM_NONCOHERENT) if the runlist object resides in system
memory.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
DMA mask is typically set in nouveau_ttm_init(), but this function is
called late during initialization and GK20A's instmem will have called
DMA functions before this happens.
Having a wrongly set DMA mask can result in the use of unneeded bounce
buffers. Set it early to avoid this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Karol Herbst [Thu, 18 Feb 2016 15:53:44 +0000 (16:53 +0100)]
drm/nouveau/iccsense: implement for ina209, ina219 and ina3221
based on Martins initial work
v3: fix ina2x9 calculations
v4: don't kmalloc(0), fix the lsb/pga stuff
v5: add a field to tell if the power reading may be invalid
add nkvm_iccsense_read_all function
check for the device on the i2c bus
Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Reviewed-by: Martin Peres <martin.peres@free.fr>
drm/nouveau/secboot/gm20b: add secure boot support
Add secure boot support for the GM20B chip found in Tegra X1. Secure
boot on Tegra works slightly differently from desktop, notably in the
way the WPR region is set up.
In addition, the firmware bootloaders use a slightly different header
format.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
On GM200 and later GPUs, firmware for some essential falcons (notably
GR ones) must be authenticated by a NVIDIA-produced signature and
loaded by a high-secure falcon in order to be able to access privileged
registers, in a process known as Secure Boot.
Secure Boot requires building a binary blob containing the firmwares
and signatures of the falcons to be loaded. This blob is then given to
a high-secure falcon running a signed loader firmware that copies the
blob into a write-protected region, checks that the signatures are
valid, and finally loads the verified firmware into the managed falcons
and switches them to privileged mode.
This patch adds infrastructure code to support this process on chips
that require it.
v2:
- The IRQ mask of the PMU falcon was left - replace it with the proper
irq_mask variable.
- The falcon reset procedure expecting a falcon in an initialized state,
which was accidentally provided by the PMU subdev. Make sure that
secboot can manage the falcon on its own.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/gr/gf100: load firmware in outer function
The firmwares required by GR may vary from chip to chip, especially with
the introduction of secure boot and NVIDIA-provided firmwares. Move the
firmware loading outside of gf100_gr_ctor so other chips may still call
it while managing their firmwares themselves.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/gr/gk20a: move firmware bundle release to gf100
Some members of gf100_gr were freed by the gk20a driver. That's not
where it should be done - free them in gf100 so other chips that use
NVIDIA-provided firmware free these structures properly.
This also removes the need for a GK20A-specific destructor.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
projects / linux-beck.git / log