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
...
Alexandre Courbot [Fri, 12 Feb 2016 05:19:27 +0000 (14:19 +0900)]
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>
Alexandre Courbot [Fri, 12 Feb 2016 05:13:21 +0000 (14:13 +0900)]
drm/nouveau/clk/gk20a: fix VCO bit mask
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>
Alexandre Courbot [Tue, 1 Mar 2016 07:59:05 +0000 (16:59 +0900)]
drm/nouveau/fifo/gk104: kick channel upon removal
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>
Alexandre Courbot [Thu, 3 Mar 2016 07:38:12 +0000 (16:38 +0900)]
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>
Alexandre Courbot [Wed, 2 Mar 2016 10:13:42 +0000 (19:13 +0900)]
drm/nouveau/hwmon: fix crash on non-PCI platforms
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>
Alexandre Courbot [Wed, 2 Mar 2016 10:12:27 +0000 (19:12 +0900)]
drm/nouveau/bo: consider DMA buffers on x86 only
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>
Alexandre Courbot [Tue, 1 Mar 2016 07:51:58 +0000 (16:51 +0900)]
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>
Alexandre Courbot [Tue, 1 Mar 2016 07:51:57 +0000 (16:51 +0900)]
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>
Alexandre Courbot [Thu, 25 Feb 2016 06:08:42 +0000 (15:08 +0900)]
drm/nouveau/instmem/gk20a: set DMA mask early
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>
Alexandre Courbot [Wed, 24 Feb 2016 05:42:24 +0000 (14:42 +0900)]
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>
Alexandre Courbot [Wed, 24 Feb 2016 05:42:20 +0000 (14:42 +0900)]
drm/nouveau/core: add support for secure boot
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>
Alexandre Courbot [Wed, 24 Feb 2016 05:42:16 +0000 (14:42 +0900)]
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>
Alexandre Courbot [Wed, 24 Feb 2016 05:42:15 +0000 (14:42 +0900)]
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>
Ben Skeggs [Wed, 24 Feb 2016 04:03:40 +0000 (14:03 +1000)]
drm/nouveau/gr/gm200: s/gm204/gm200/
Most of the per-chipset differences will go away when we fully switch
to using the register lists provided by the firmware files, which will
leave all the remaining code "belonging" to GM200.
Alexandre Courbot [Thu, 11 Feb 2016 02:10:04 +0000 (11:10 +0900)]
drm/nouveau/devinit/gf100-: detect if BIOS invoked devinit
It is not advisable to perform devinit if it has already been done.
VBIOS will very likely have invoked devinit if the GPU is the primary
graphics device, but there is no accurate way to detect this fact yet.
This patch adds such a method for gf100 and later chips, by means of the
NV_PTOP_SCRATCH1_DEVINIT_COMPLETED bit. This bit is set to 1 by devinit,
and reset to 0 when the GPU is powered.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Alexandre Courbot [Thu, 28 Jan 2016 03:30:06 +0000 (12:30 +0900)]
drm/nouveau/device/tegra: fix uninitialized IRQ number
nvkm_device_tegra_new initializes the irq member of the Tegra device
to -1 in order to signal that it is uninitialized. However,
nvkm_device_tegra_fini tests it against 0 to check whether an IRQ has
been allocated or not. This leads to free_irq being called on -1 during
device initialization.
Fix this by using 0 as the uninitialized value everywhere.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Alexandre Courbot [Mon, 25 Jan 2016 09:44:23 +0000 (18:44 +0900)]
drm/nouveau/device: call nvkm_device_fini if nvkm_device_init fails
nvkm_device_fini is never called if a failure occurs in
nvkm_device_init, even when unloading the module. This can lead to a
resources leak (one example is the Tegra interrupt which would never be
freed in that case). Fix this by calling nvkm_device_fini in
nvkm_device_init's failure path.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
projects / users / hch / misc.git / log