openwrt/staging/blogic.git
8 years agodrm/nouveau/clk/gk20a: abstract pl_to_div
Alexandre Courbot [Fri, 12 Feb 2016 04:56:38 +0000 (13:56 +0900)]
drm/nouveau/clk/gk20a: abstract pl_to_div

pl_to_div may be done differently depending on the chip. Abstract this
operation so the same logic can be reused for them as well.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/clk/gk20a: put mnp values into their own struct
Alexandre Courbot [Wed, 28 Oct 2015 09:31:28 +0000 (18:31 +0900)]
drm/nouveau/clk/gk20a: put mnp values into their own struct

This allows us to read them using one single function and will be handy
to the GM20B driver.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/clk/gk20a: emit parent rate as debug message
Alexandre Courbot [Fri, 12 Feb 2016 08:22:53 +0000 (17:22 +0900)]
drm/nouveau/clk/gk20a: emit parent rate as debug message

Most users are probably not interested in this information.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/clk/gk20a: only restore divider to 1:1 if needed
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>
8 years agodrm/nouveau/clk/gk20a: only compute n_lo if needed
Alexandre Courbot [Fri, 12 Feb 2016 05:15:57 +0000 (14:15 +0900)]
drm/nouveau/clk/gk20a: only compute n_lo if needed

n_lo is used if we are going to slide. Compute it only if that condition
succeeds to avoid confusion about future usage of this computation.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/clk/gk20a: fix VCO bit mask
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>
8 years agodrm/nouveau/clk/gk20a: rename enable/disable functions
Alexandre Courbot [Fri, 12 Feb 2016 05:07:07 +0000 (14:07 +0900)]
drm/nouveau/clk/gk20a: rename enable/disable functions

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>
8 years agodrm/nouveau/clk/gk20a: reorganize variables in gk20a_pllg_calc_mnp()
Alexandre Courbot [Fri, 12 Feb 2016 05:05:01 +0000 (14:05 +0900)]
drm/nouveau/clk/gk20a: reorganize variables in gk20a_pllg_calc_mnp()

Move some variables declarations to the scope where they are actually
used to make the code easier to follow.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/clk/gk20a: convert parameters to Khz
Alexandre Courbot [Wed, 28 Oct 2015 08:36:06 +0000 (17:36 +0900)]
drm/nouveau/clk/gk20a: convert parameters to Khz

Perform computations in Khz instead of Mhz for better precision.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/volt: add GM20B driver
Alexandre Courbot [Tue, 27 Oct 2015 03:35:14 +0000 (12:35 +0900)]
drm/nouveau/volt: add GM20B driver

Add basic GM20B volt driver that reuses the GK20A logic.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/volt/gk20a: split constructor
Alexandre Courbot [Fri, 12 Feb 2016 08:44:21 +0000 (17:44 +0900)]
drm/nouveau/volt/gk20a: split constructor

Split the constructor function so we can reuse the same logic in other
chips.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/volt/gk20a: share reusable members & functions
Vince Hsu [Mon, 27 Apr 2015 03:48:02 +0000 (11:48 +0800)]
drm/nouveau/volt/gk20a: share reusable members & functions

The CVB calculation and voltage setting functions can be reused for the
future chips. So move the declaration to gk20a.h.

Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/ce/gm107: expose MaxwellDmaCopyA
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/ce/gm107: expose MaxwellDmaCopyA

The HW accepts KeplerDmaCopyA and MaxwellDmaCopyA classes.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gm107: KeplerChannelGpfifoB, and 2048 channels
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gm107: KeplerChannelGpfifoB, and 2048 channels

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk110: expose KeplerChannelGpfifoB
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk110: expose KeplerChannelGpfifoB

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.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: submit NOP after all PBDMA_INTR_0, not just DEVICE
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: submit NOP after all PBDMA_INTR_0, not just DEVICE

Prevents the same interrupt from re-triggering forever.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: add vic plumbing
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: add vic plumbing

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: add sec plumbing
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: add sec plumbing

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: add nvdec plumbing
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: add nvdec plumbing

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: add nvenc plumbing
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: add nvenc plumbing

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: add msenc plumbing
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: add msenc plumbing

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/core: add vic plumbing
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/core: add vic plumbing

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/core: add nvdec plumbing
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/core: add nvdec plumbing

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/core: add nvenc plumbing
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/core: add nvenc plumbing

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/core: add msenc plumbing
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/core: add msenc plumbing

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/core: sort engine indices alphabetically
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/core: sort engine indices alphabetically

Unlike subdevs, these aren't initialised in a defined order.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: make use of topology info during gpfifo construction
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: make use of topology info during gpfifo construction

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: make use of topology info during fault recovery
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: make use of topology info during fault recovery

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: make use of topology info when handling ctxsw timeout
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: make use of topology info when handling ctxsw timeout

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: read device topology information from hw
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: read device topology information from hw

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: cosmetic engine->runlist changes
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: cosmetic engine->runlist changes

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: don't attempt recovery of unknown mmu engines
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: don't attempt recovery of unknown mmu engines

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: identify fault-recovery members more clearly
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: identify fault-recovery members more clearly

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: rename spoon to pbdma, and move detection to oneinit
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gk104: rename spoon to pbdma, and move detection to oneinit

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gf100: fix certain engines not being recovered after a fault
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gf100: fix certain engines not being recovered after a fault

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gf100: don't attempt recovery of unknown mmu engines
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gf100: don't attempt recovery of unknown mmu engines

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gf100: identify fault-recovery members more clearly
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gf100: identify fault-recovery members more clearly

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gf100: rename spooon to pbdma, and move detection to oneinit
Ben Skeggs [Fri, 11 Mar 2016 03:09:28 +0000 (13:09 +1000)]
drm/nouveau/fifo/gf100: rename spooon to pbdma, and move detection to oneinit

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/gr/fuc: Store $r0 in interrupt handler
Roy Spliet [Thu, 10 Mar 2016 11:19:00 +0000 (11:19 +0000)]
drm/nouveau/gr/fuc: Store $r0 in interrupt handler

It's supposed to always be 0, but at least nv_iowr() temporarily violates
this. Since the ih touches $r0, it should be stored.

Signed-off-by: Roy Spliet <rs855@cam.ac.uk>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/pmu/fuc: use imm32 in ld/st macros
Karol Herbst [Wed, 2 Mar 2016 16:23:07 +0000 (17:23 +0100)]
drm/nouveau/pmu/fuc: use imm32 in ld/st macros

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/pmu/fuc: use the call macro instead of using the call instruction directly
Karol Herbst [Wed, 2 Mar 2016 16:23:06 +0000 (17:23 +0100)]
drm/nouveau/pmu/fuc: use the call macro instead of using the call instruction directly

the macro deals with target specific differences and so we should always use
this

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/pmu/fuc: replace mov+sethi with imm32
Karol Herbst [Wed, 2 Mar 2016 16:23:05 +0000 (17:23 +0100)]
drm/nouveau/pmu/fuc: replace mov+sethi with imm32

on gk208+ we can simply mov 32bits, so we should have a single mov there

v2: use or operator instead of add

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/pmu/fuc: fix imm32 for gk208+
Karol Herbst [Wed, 2 Mar 2016 16:23:04 +0000 (17:23 +0100)]
drm/nouveau/pmu/fuc: fix imm32 for gk208+

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/core: use vzalloc for allocating ramht
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>
8 years agodrm/nouveau/fifo/gk104: kick channel upon removal
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>
8 years agodrm/nouveau/instmem/gk20a: add write barrier when releasing DMA object
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>
8 years agodrm/nouveau/device/pci: set as non-CPU-coherent on ARM64
Alexandre Courbot [Thu, 3 Mar 2016 07:03:02 +0000 (16:03 +0900)]
drm/nouveau/device/pci: set as non-CPU-coherent on ARM64

Without this buffer inconsistencies may appear between the CPU
and GPU when using a PCI GPU on an ARM64 board.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/hwmon: fix crash on non-PCI platforms
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>
8 years agodrm/nouveau: silence unimportant HDMI status message
Alexandre Courbot [Wed, 2 Mar 2016 10:13:03 +0000 (19:13 +0900)]
drm/nouveau: silence unimportant HDMI status message

On non-PCI devices, nobody should really care if the device does not
provide HDMI...

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/bo: consider DMA buffers on x86 only
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>
8 years agodrm/nouveau/ltc/gf100: use more reasonable timeout value
Alexandre Courbot [Tue, 1 Mar 2016 08:39:00 +0000 (17:39 +0900)]
drm/nouveau/ltc/gf100: use more reasonable timeout value

LTC operations timeout was set to 2ms, which may be too low for devices
that run at very low clocks (e.g. GM20B) and trigger timeout messages.

Set the timeout to the default 2s. Also remove the redundant error
messages since nvkm_wait_msec() will already display a warning.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/fifo/gk104: take runlist target into account
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>
8 years agodrm/nouveau/fifo/gf100: take runlist target into account
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>
8 years agodrm/nouveau/fifo/gk104: fix chid bit mask
Xia Yang [Thu, 25 Feb 2016 08:59:08 +0000 (17:59 +0900)]
drm/nouveau/fifo/gk104: fix chid bit mask

Fix the channel id bit mask in FIFO schedule timeout error handling.

FIFO_ENGINE_STATUS_NEXT_ID is bit 27:16 thus 0x0fff0000.
FIFO_ENGINE_STATUS_ID      is bit 11:0  thus 0x00000fff.

Signed-off-by: Xia Yang <xiay@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/instmem/gk20a: set DMA mask early
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>
8 years agodrm/nouveau/gr/gm206: remove implementation, it's now identical to gm200
Ben Skeggs [Thu, 25 Feb 2016 00:40:51 +0000 (10:40 +1000)]
drm/nouveau/gr/gm206: remove implementation, it's now identical to gm200

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/gr/gm200: switch over to using sw_nonctx from firmware
Ben Skeggs [Thu, 25 Feb 2016 00:03:13 +0000 (10:03 +1000)]
drm/nouveau/gr/gm200: switch over to using sw_nonctx from firmware

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/gr/gm200: switch over to using sw_method_init from firmware
Ben Skeggs [Thu, 25 Feb 2016 00:00:17 +0000 (10:00 +1000)]
drm/nouveau/gr/gm200: switch over to using sw_method_init from firmware

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/gr/gm200: switch over to using sw_bundle_init from firmware
Ben Skeggs [Wed, 24 Feb 2016 23:58:12 +0000 (09:58 +1000)]
drm/nouveau/gr/gm200: switch over to using sw_bundle_init from firmware

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/gr/gm200: switch over to using sw_ctx from firmware
Ben Skeggs [Wed, 24 Feb 2016 23:48:37 +0000 (09:48 +1000)]
drm/nouveau/gr/gm200: switch over to using sw_ctx from firmware

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/bios/extdev: also parse v4.1 table
Karol Herbst [Sat, 20 Feb 2016 16:12:19 +0000 (17:12 +0100)]
drm/nouveau/bios/extdev: also parse v4.1 table

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
8 years agodrm/nouveau/hwmon: don't require therm to be valid to get any data
Karol Herbst [Sat, 20 Feb 2016 16:10:12 +0000 (17:10 +0100)]
drm/nouveau/hwmon: don't require therm to be valid to get any data

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
8 years agodrm/nouveau/hwmon: add power consumption
Karol Herbst [Thu, 18 Feb 2016 19:10:19 +0000 (20:10 +0100)]
drm/nouveau/hwmon: add power consumption

v2: expose only if the sensor reading is valid

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
8 years agodrm/nouveau/iccsense: implement for ina209, ina219 and ina3221
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>
8 years agodrm/nouveau/nvbios/iccsense: add parsing of the SENSE table
Martin Peres [Thu, 18 Feb 2016 13:35:12 +0000 (14:35 +0100)]
drm/nouveau/nvbios/iccsense: add parsing of the SENSE table

Karol Herbst:
v4: don't kmalloc(0)
v5: stricter validation

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
8 years agodrm/nouveau/subdev/iccsense: add new subdev for power sensors
Martin Peres [Thu, 18 Feb 2016 13:10:49 +0000 (14:10 +0100)]
drm/nouveau/subdev/iccsense: add new subdev for power sensors

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
8 years agodrm/nouveau/secboot/gm20b: add secure boot support
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>
8 years agodrm/nouveau/secboot/gm200: add secure-boot support
Alexandre Courbot [Wed, 24 Feb 2016 05:42:23 +0000 (14:42 +0900)]
drm/nouveau/secboot/gm200: add secure-boot support

Add secure-boot for the dGPU set of GM20X chips, using the PMU as the
high-secure falcon.

This work is based on Deepak Goyal's initial port of Secure Boot to
Nouveau.

v2. use proper memory target function

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/gr/gm200: do not load firmware for secure falcons
Alexandre Courbot [Wed, 24 Feb 2016 05:42:22 +0000 (14:42 +0900)]
drm/nouveau/gr/gm200: do not load firmware for secure falcons

Secure falcons' firmware is managed by secboot. Do not load it in GR for
them.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/gr/gf100: add support for securely-managed falcons
Alexandre Courbot [Wed, 24 Feb 2016 05:42:21 +0000 (14:42 +0900)]
drm/nouveau/gr/gf100: add support for securely-managed falcons

Start securely-managed falcons using secboot functions since the process
for them is different from just writing CPUCTL.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/core: add support for secure boot
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>
8 years agodrm/nouveau/gr/gm200: load external firmware and bundles
Alexandre Courbot [Wed, 24 Feb 2016 05:42:19 +0000 (14:42 +0900)]
drm/nouveau/gr/gm200: load external firmware and bundles

Load firmware and bundles in GM200's constructor. The previously called
GF100 function did not care about the bundles.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/gr/gk20a: share external bundles loading functions
Alexandre Courbot [Wed, 24 Feb 2016 05:42:18 +0000 (14:42 +0900)]
drm/nouveau/gr/gk20a: share external bundles loading functions

There functions are going to be used by other chips that rely on
NVIDIA-provided firmware. Export them.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/gr/gk20a: simplify external bundle loading functions
Alexandre Courbot [Wed, 24 Feb 2016 05:42:17 +0000 (14:42 +0900)]
drm/nouveau/gr/gk20a: simplify external bundle loading functions

Make these functions easier to use by handling memory management from
within.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/gr/gf100: load firmware in outer function
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>
8 years agodrm/nouveau/gr/gk20a: move firmware bundle release to gf100
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>
8 years agodrm/nouveau/core: add gpuobj memcpy helper functions
Alexandre Courbot [Wed, 24 Feb 2016 05:42:14 +0000 (14:42 +0900)]
drm/nouveau/core: add gpuobj memcpy helper functions

Add memcpy functions to copy a buffer to a gpuobj and vice-versa. This
will be used by the secure boot code.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/gm200: enable graphics device
Ben Skeggs [Wed, 24 Feb 2016 04:05:54 +0000 (14:05 +1000)]
drm/nouveau/gm200: enable graphics device

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/gr/gm200: s/gm204/gm200/
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.

This is a preemptive rename from GM204 to GM200.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/bios/devinit: properly handle unknown generic conditions
Ben Skeggs [Wed, 17 Feb 2016 18:10:04 +0000 (04:10 +1000)]
drm/nouveau/bios/devinit: properly handle unknown generic conditions

Upon encountering an unknown condition code, the script interpreter
is supposed to skip 'size' bytes and continue at the next devinit
token.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/bios/devinit: rename INIT_DP_CONDITION to INIT_GENERIC_CONDITION
Ben Skeggs [Wed, 17 Feb 2016 18:03:39 +0000 (04:03 +1000)]
drm/nouveau/bios/devinit: rename INIT_DP_CONDITION to INIT_GENERIC_CONDITION

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/ltc/gm107: fix slice intr offset
Ben Skeggs [Thu, 11 Feb 2016 02:23:03 +0000 (12:23 +1000)]
drm/nouveau/ltc/gm107: fix slice intr offset

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/devinit/gf100-: detect if BIOS invoked devinit
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>
8 years agodrm/nouveau/devinit/nv50: remove unneeded variable
Alexandre Courbot [Thu, 11 Feb 2016 02:09:52 +0000 (11:09 +0900)]
drm/nouveau/devinit/nv50: remove unneeded variable

We never use any nv50-specific member in this nv50_devinit_preinit().

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau: s/gm204/gm200/ in a number of places
Ben Skeggs [Wed, 10 Feb 2016 22:35:32 +0000 (08:35 +1000)]
drm/nouveau: s/gm204/gm200/ in a number of places

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau: recognise GM200 chipset
Ben Skeggs [Wed, 10 Feb 2016 22:25:35 +0000 (08:25 +1000)]
drm/nouveau: recognise GM200 chipset

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/device/tegra: fix uninitialized IRQ number
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>
8 years agodrm/nouveau/device: call nvkm_device_fini if nvkm_device_init fails
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>
8 years agodrm/nouveau/gr/gf100: use the nvkm_firmware functions
Alexandre Courbot [Mon, 18 Jan 2016 06:07:10 +0000 (15:07 +0900)]
drm/nouveau/gr/gf100: use the nvkm_firmware functions

Use the nvkm_firmware_* functions when loading external firmware to
avoid duplicate code.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/core: add firmware handling functions
Alexandre Courbot [Mon, 18 Jan 2016 06:07:09 +0000 (15:07 +0900)]
drm/nouveau/core: add firmware handling functions

Add two functions nvkm_firmware_get() and nvkm_firmware_put() to load a
firmware file and free its resources, respectively. Since firmware files
are becoming a necessity for new GPUs, and their location has been
standardized to nvidia/chip/, this will prevent duplicate and
error-prone name-generation code.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agodrm/nouveau/ltc/gm107: wait on relevant bit in gm107_ltc_cbc_wait
Alexandre Courbot [Fri, 15 Jan 2016 02:53:24 +0000 (11:53 +0900)]
drm/nouveau/ltc/gm107: wait on relevant bit in gm107_ltc_cbc_wait

Patch "ltc/gm107: use nvkm_mask to set cbc_ctrl1" sets the 3rd bit
of the CTRL1 register instead of writing it entirely in
gm107_ltc_cbc_clear(). As a counterpart, gm107_ltc_cbc_wait() must also
be modified to wait on that single bit only, otherwise a timeout may
occur if some other bit of that register is set. This happened at least
on GM206 when running glmark2-drm.

While we are at it, use the more compact nvkm_wait_msec() to wait for
the bit to clear.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8 years agoMerge tag 'drm-vc4-fixes-2016-03-03' of github.com:anholt/linux into drm-next
Dave Airlie [Sun, 13 Mar 2016 23:48:04 +0000 (09:48 +1000)]
Merge tag 'drm-vc4-fixes-2016-03-03' of github.com:anholt/linux into drm-next

This pull request fixes the major VC4 HDMI modesetting bugs found when
the first wave of users showed up in Raspbian.

* tag 'drm-vc4-fixes-2016-03-03' of github.com:anholt/linux:
  drm/vc4: Initialize scaler DISPBKGND on modeset.
  drm/vc4: Fix setting of vertical timings in the CRTC.
  drm/vc4: Fix the name of the VSYNCD_EVEN register.
  drm/vc4: Add another reg to HDMI debug dumping.
  drm/vc4: Bring HDMI up from power off if necessary.
  drm/vc4: Fix a framebuffer reference leak on async flip interrupt.

8 years agoMerge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daein...
Dave Airlie [Sun, 13 Mar 2016 23:46:46 +0000 (09:46 +1000)]
Merge branch 'exynos-drm-next' of git://git./linux/kernel/git/daeinki/drm-exynos into drm-next

* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl

8 years agoMerge drm-fixes into drm-next.
Dave Airlie [Sun, 13 Mar 2016 23:42:34 +0000 (09:42 +1000)]
Merge drm-fixes into drm-next.

Nouveau wanted this to avoid some worse conflicts when I merge that.

8 years agodrm/exynos: add DRM_EXYNOS_GEM_MAP ioctl
Joonyoung Shim [Tue, 8 Mar 2016 05:12:59 +0000 (14:12 +0900)]
drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl

The commit d931589c01a2 ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET
ioctl") removed it same with the ioctl that this patch adds. The reason
that removed DRM_EXYNOS_GEM_MAP_OFFSET was we could use
DRM_IOCTL_MODE_MAP_DUMB. Both did exactly same thing.

Now we again will revive it as DRM_EXYNOS_GEM_MAP because of render
node. DRM_IOCTL_MODE_MAP_DUMB isn't permitted in render node.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
8 years agoMerge tag 'drm-intel-fixes-2016-03-11' of git://anongit.freedesktop.org/drm-intel...
Dave Airlie [Fri, 11 Mar 2016 20:53:30 +0000 (06:53 +1000)]
Merge tag 'drm-intel-fixes-2016-03-11' of git://anongit.freedesktop.org/drm-intel into drm-next

Two i915 regression fixes.

* tag 'drm-intel-fixes-2016-03-11' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Actually retry with bit-banging after GMBUS timeout
  drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW

8 years agoMerge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Linus Torvalds [Fri, 11 Mar 2016 20:35:54 +0000 (12:35 -0800)]
Merge tag 'armsoc-fixes' of git://git./linux/kernel/git/arm/arm-soc

Pull ARM SoC fixes from Olof Johansson:
 "Two more fixes for 4.5:

   - One is a fix for OMAP that is urgently needed to avoid DRA7xx chips
     from premature aging, by always keeping the Ethernet clock enabled.

   - The other solves a I/O memory layout issue on Armada, where SROM
     and PCI memory windows were conflicting in some configurations"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory window
  ARM: dts: dra7: do not gate cpsw clock due to errata i877
  ARM: OMAP2+: hwmod: Introduce ti,no-idle dt property

8 years agoMerge tag 'media/v4.5-5' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab...
Linus Torvalds [Fri, 11 Mar 2016 20:32:02 +0000 (12:32 -0800)]
Merge tag 'media/v4.5-5' of git://git./linux/kernel/git/mchehab/linux-media

Pull media fix from Mauro Carvalho Chehab:
 "One last time fix: It adds a code that prevents some media tools like
  media-ctl to hide some entities that have their IDs out of the range
  expected by those apps"

* tag 'media/v4.5-5' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] media-device: map new functions into old types for legacy API

8 years agoARM: mvebu: fix overlap of Crypto SRAM with PCIe memory window
Thomas Petazzoni [Tue, 8 Mar 2016 15:59:57 +0000 (16:59 +0100)]
ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory window

When the Crypto SRAM mappings were added to the Device Tree files
describing the Armada XP boards in commit c466d997bb16 ("ARM: mvebu:
define crypto SRAM ranges for all armada-xp boards"), the fact that
those mappings were overlaping with the PCIe memory aperture was
overlooked. Due to this, we currently have for all Armada XP platforms
a situation that looks like this:

Memory mapping on Armada XP boards with internal registers at
0xf1000000:

 - 0x00000000 -> 0xf0000000 3.75G  RAM
 - 0xf0000000 -> 0xf1000000 16M NOR flashes (AXP GP / AXP DB)
 - 0xf1000000 -> 0xf1100000 1M internal registers
 - 0xf8000000 -> 0xffe0000 126M PCIe memory aperture
 - 0xf8100000 -> 0xf8110000 64KB Crypto SRAM #0 => OVERLAPS WITH PCIE !
 - 0xf8110000 -> 0xf8120000 64KB Crypto SRAM #1 => OVERLAPS WITH PCIE !
 - 0xffe00000 -> 0xfff00000 1M PCIe I/O aperture
 - 0xfff0000  -> 0xffffffff 1M BootROM

The overlap means that when PCIe devices are added, depending on their
memory window needs, they might or might not be mapped into the
physical address space. Indeed, they will not be mapped if the area
allocated in the PCIe memory aperture by the PCI core overlaps with
one of the Crypto SRAM. Typically, a Intel IGB PCIe NIC that needs 8MB
of PCIe memory will see its PCIe memory window allocated from
0xf80000000 for 8MB, which overlaps with the Crypto SRAM windows. Due
to this, the PCIe window is not created, and any attempt to access the
PCIe window makes the kernel explode:

[    3.302213] igb: Copyright (c) 2007-2014 Intel Corporation.
[    3.307841] pci 0000:00:09.0: enabling device (0140 -> 0143)
[    3.313539] mvebu_mbus: cannot add window '4:f8', conflicts with another window
[    3.320870] mvebu-pcie soc:pcie-controller: Could not create MBus window at [mem 0xf8000000-0xf87fffff]: -22
[    3.330811] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf08c0018

This problem does not occur on Armada 370 boards, because we use the
following memory mapping (for boards that have internal registers at
0xf1000000):

 - 0x00000000 -> 0xf0000000 3.75G  RAM
 - 0xf0000000 -> 0xf1000000 16M NOR flashes (AXP GP / AXP DB)
 - 0xf1000000 -> 0xf1100000 1M internal registers
 - 0xf1100000 -> 0xf1110000 64KB Crypto SRAM #0 => OK !
 - 0xf8000000 -> 0xffe0000 126M PCIe memory
 - 0xffe00000 -> 0xfff00000 1M PCIe I/O
 - 0xfff0000  -> 0xffffffff 1M BootROM

Obviously, the solution is to align the location of the Crypto SRAM
mappings of Armada XP to be similar with the ones on Armada 370, i.e
have them between the "internal registers" area and the beginning of
the PCIe aperture.

However, we have a special case with the OpenBlocks AX3-4 platform,
which has a 128 MB NOR flash. Currently, this NOR flash is mapped from
0xf0000000 to 0xf8000000. This is possible because on OpenBlocks
AX3-4, the internal registers are not at 0xf1000000. And this explains
why the Crypto SRAM mappings were not configured at the same place on
Armada XP.

Hence, the solution is two-fold:

 (1) Move the NOR flash mapping on Armada XP OpenBlocks AX3-4 from
     0xe8000000 to 0xf0000000. This frees the 0xf0000000 ->
     0xf80000000 space.

 (2) Move the Crypto SRAM mappings on Armada XP to be similar to
     Armada 370 (except of course that Armada XP has two Crypto SRAM
     and not one).

After this patch, the memory mapping on Armada XP boards with
registers at 0xf1 is:

 - 0x00000000 -> 0xf0000000 3.75G  RAM
 - 0xf0000000 -> 0xf1000000 16M NOR flashes (AXP GP / AXP DB)
 - 0xf1000000 -> 0xf1100000 1M internal registers
 - 0xf1100000 -> 0xf1110000 64KB Crypto SRAM #0
 - 0xf1110000 -> 0xf1120000 64KB Crypto SRAM #1
 - 0xf8000000 -> 0xffe0000 126M PCIe memory
 - 0xffe00000 -> 0xfff00000 1M PCIe I/O
 - 0xfff0000  -> 0xffffffff 1M BootROM

And the memory mapping for the special case of the OpenBlocks AX3-4
(internal registers at 0xd0000000, NOR of 128 MB):

 - 0x00000000 -> 0xc0000000 3G  RAM
 - 0xd0000000 -> 0xd1000000 1M internal registers
 - 0xe800000  -> 0xf0000000 128M NOR flash
 - 0xf1100000 -> 0xf1110000 64KB Crypto SRAM #0
 - 0xf1110000 -> 0xf1120000 64KB Crypto SRAM #1
 - 0xf8000000 -> 0xffe0000 126M PCIe memory
 - 0xffe00000 -> 0xfff00000 1M PCIe I/O
 - 0xfff0000  -> 0xffffffff 1M BootROM

Fixes: c466d997bb16 ("ARM: mvebu: define crypto SRAM ranges for all armada-xp boards")
Reported-by: Phil Sutter <phil@nwl.cc>
Cc: Phil Sutter <phil@nwl.cc>
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
8 years agoMerge tag 'dmaengine-fix-4.5' of git://git.infradead.org/users/vkoul/slave-dma
Linus Torvalds [Fri, 11 Mar 2016 18:57:18 +0000 (10:57 -0800)]
Merge tag 'dmaengine-fix-4.5' of git://git.infradead.org/users/vkoul/slave-dma

Pull dmaengine fixes from Vinod Koul:
 "Two fixes showed up in last few days, and they should be included in
  4.5.  Summary:

  Two more late fixes to drivers, nothing major here:

   - A memory leak fix in fsdma unmap the dma descriptors on freeup

   - A fix in xdmac driver for residue calculation of dma descriptor"

* tag 'dmaengine-fix-4.5' of git://git.infradead.org/users/vkoul/slave-dma:
  dmaengine: at_xdmac: fix residue computation
  dmaengine: fsldma: fix memory leak