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>
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>
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>
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.
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.
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
Linus Torvalds [Fri, 11 Mar 2016 20:35:54 +0000 (12:35 -0800)]
Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/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
Linus Torvalds [Fri, 11 Mar 2016 20:32:02 +0000 (12:32 -0800)]
Merge tag 'media/v4.5-5' of git://git.kernel.org/pub/scm/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
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:
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):
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:
projects / users / hch / misc.git / log