- 14 Mar, 2016 34 commits
-
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Karol Herbst authored
Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Reviewed-by: Martin Peres <martin.peres@free.fr>
-
Karol Herbst authored
Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Reviewed-by: Martin Peres <martin.peres@free.fr>
-
Karol Herbst authored
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>
-
Karol Herbst authored
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>
-
Martin Peres authored
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>
-
Martin Peres authored
Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Reviewed-by: Martin Peres <martin.peres@free.fr>
-
Alexandre Courbot authored
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 authored
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>
-
Alexandre Courbot authored
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>
-
Alexandre Courbot authored
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>
-
Alexandre Courbot authored
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 authored
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>
-
Alexandre Courbot authored
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>
-
Alexandre Courbot authored
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>
-
Alexandre Courbot authored
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 authored
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>
-
Alexandre Courbot authored
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>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
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 authored
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>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Alexandre Courbot authored
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 authored
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 authored
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>
-
Alexandre Courbot authored
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 authored
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>
-
- 13 Mar, 2016 4 commits
-
-
Dave Airlie authored
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.
-
Dave Airlie authored
Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/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
-
Dave Airlie authored
Nouveau wanted this to avoid some worse conflicts when I merge that.
-
Joonyoung Shim authored
The commit d931589c ("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>
-
- 11 Mar, 2016 2 commits
-
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
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
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
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
-