Displaying 20 results from an estimated 3000 matches similar to: "[bug report] null ptr deref in nouveau_platform_probe (tegra186-p2771-0000)"
2017 Dec 21
2
[bug report] null ptr deref in nouveau_platform_probe (tegra186-p2771-0000)
Hi Thierry,
Thanks for the patch. I applied on top of linux-next-2017-12-14.
Different output this time.
[ 11.862495] WARNING: CPU: 1 PID: 254 at
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:391
gf100_vmm_new_+0x60/0x128 [nouveau]
[ 11.863458] tegra-dpaux 155c0000.dpaux: 155c0000.dpaux supply vdd
not found, using dummy regulator
[ 11.866197] tegra-sor 15580000.sor: failed to probe
2017 Dec 21
1
[bug report] null ptr deref in nouveau_platform_probe (tegra186-p2771-0000)
I applied the changes manually. This time, Xorg is actually starting...
[ 16.862744] WARNING: CPU: 3 PID: 381 at
drivers/gpu/drm/nouveau/nouveau_bo.c:280 nouveau_bo_new+0x450/0x4d0
[nouveau]
[ 16.873333] Modules linked in: nouveau i2c_algo_bit ttm tegra_drm
gpio_keys drm_kms_helper drm drm_panel_orientation_quirks(P) host1x
dwmac_dwc_qos_eth stmmac_platform stmmac ptp pps_core
syscopyarea
2017 Nov 21
2
GP10B regression
Thanks to Thierry for finding this - applying
index e14643615698..00eeaaffeae5 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -2369,7 +2369,7 @@ nv13b_chipset = {
.imem = gk20a_instmem_new,
.ltc = gp100_ltc_new,
.mc = gp10b_mc_new,
- .mmu = gf100_mmu_new,
+ .mmu = gp10b_mmu_new,
2020 May 06
4
GeForce(R) GT 710 1GB PCIE x 1 on arm64
Hi to all.
I'm experimenting with running a
https://www.zotac.com/us/product/graphics_card/geforce%C2%AE-gt-710-1gb-pcie-x-1
card on an Nvidia Jetson TX2 arm64 device.
Possible?
Linux kernel aarch64 5.6.10.
Because Nvidia did not list drivers for this architecture, I'm
experimenting with a nouveau driver.
The Jetson TX2 has a default driver for the host1x framebuffer for output
from the
2020 May 06
0
Fwd: GeForce(R) GT 710 1GB PCIE x 1 on arm64
---------- Forwarded message ---------
Od: Milan Bu?ka <milan.buska at gmail.com>
Date: st 6. 5. 2020 v 16:15
Subject: Re: [Nouveau] GeForce(R) GT 710 1GB PCIE x 1 on arm64
To: Ilia Mirkin <imirkin at alum.mit.edu>
Here is:
# dmesg
[ 0.000000] Booting Linux on physical CPU 0x0000000100 [0x411fd073]
[ 0.000000] Linux version 5.6.10-zotac (root at saux) (gcc version
9.3.0 (SAUX
2019 Sep 16
15
[PATCH 00/11] drm/nouveau: Enable GP10B by default
From: Thierry Reding <treding at nvidia.com>
Hi,
the GPU on Jetson TX2 (GP10B) does not work properly on all devices. Why
exactly is not clear, but there are slight differences between the SKUs
that were tested. It turns out that the biggest issue is that on some
devices (e.g. the one that I have), pulsing the GPU reset twice as is
done in the current code (once as part of the power-ungate
2017 Jun 09
4
[PATCH 1/3] drm/nouveau/tegra: Skip manual unpowergating when not necessary
On Tegra186, powergating is handled by the BPMP power domain provider
and the "legacy" powergating API is not available. Therefore skip
these calls if we are attached to a power domain.
Signed-off-by: Mikko Perttunen <mperttunen at nvidia.com>
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
2017 Dec 20
0
[bug report] null ptr deref in nouveau_platform_probe (tegra186-p2771-0000)
On Thu, Dec 14, 2017 at 04:09:14PM -0500, Anthony Eden wrote:
> With linux-next-2017-12-14, I get a crash when nouveau is loaded by
> systemd-udevd.
>
> [ 12.050625] Unable to handle kernel NULL pointer dereference at virtual
> address 00000058
> [ 12.050627] Mem abort info:
> [ 12.050628] ESR = 0x96000004
> [ 12.050630] Exception class = DABT (current EL), IL
2018 Jan 11
1
[PATCH 1/2] drm/nouveau: Remove redundant _get
From: Thierry Reding <treding at nvidia.com>
The nouveau_fence_get_get_driver_name() function has a redundant _get in
its name. Remove it.
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
2015 Sep 04
4
[PATCH 0/4] tegra: DMA mask and IOMMU bit fixes
These 4 patches fix two issues that existed on Tegra regarding DMA:
1) The bit indicating whether to use an IOMMU or not was hardcoded ; make this
a platform property and use it in instmem
2) The DMA mask was not set for platform devices. Fix this by converting
more pci_dma* to the DMA API, and use that more generic code to set the
DMA mask properly for all platforms.
Tested on both x86
2016 Jan 25
4
[PATCH] 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 at nvidia.com>
---
2017 Jul 19
7
[PATCH 000/102] Convert drivers to explicit reset API
The reset control API has two modes: exclusive access, where the driver
expects to have full and immediate control over the state of the reset
line, and shared (clock-like) access, where drivers only request reset
deassertion while active, but don't care about the state of the reset line
while inactive.
Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset
2016 Jan 26
2
[PATCH] device/tegra: fix uninitialized IRQ number
Am Montag, den 25.01.2016, 18:44 +0900 schrieb Alexandre Courbot:
> 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.
>
The
2019 Sep 16
2
[PATCH 08/11] drm/nouveau: tegra: Skip IOMMU initialization if already attached
Hi Thierry,
On 16/09/2019 16:04, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
>
> If the GPU is already attached to an IOMMU, don't detach it and setup an
> explicit IOMMU domain. Since Nouveau can now properly handle the case of
> the DMA API being backed by an IOMMU, just continue using the DMA API.
>
> Signed-off-by: Thierry Reding
2018 May 30
8
[PATCH v4 0/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
From: Thierry Reding <treding at nvidia.com>
An unfortunate interaction between the 32-bit ARM DMA/IOMMU mapping code
and Tegra SMMU driver changes to support IOMMU groups introduced a boot-
time regression on Tegra124. This was caught very late because none of
the standard configurations that are tested on Tegra enable the ARM DMA/
IOMMU mapping code since it is not needed.
The reason for
2019 Dec 09
11
[PATCH v3 0/9] drm/nouveau: Various fixes for GP10B
From: Thierry Reding <treding at nvidia.com>
Hi Ben,
here's a revised subset of the patches I had sent out a couple of weeks
ago. I've reworked the BAR2 accesses in the way that you had suggested,
which at least for GP10B turned out to be fairly trivial to do. I have
not looked in detail at this for GV11B yet, but a cursory look showed
that BAR2 is accessed in more places, so the
2018 Apr 23
1
[PATCH] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
From: Thierry Reding <treding at nvidia.com>
Depending on the kernel configuration, early ARM architecture setup code
may have attached the GPU to a DMA/IOMMU mapping that transparently uses
the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
backed buffers (a special bit in the GPU's MMU page tables indicates the
memory path to take: via the SMMU or directly to the
2019 Nov 02
13
[PATCH v2 0/9] drm/nouveau: Various fixes for GP10B
From: Thierry Reding <treding at nvidia.com>
Hi Ben,
here's a revised subset of the patches I had sent out a couple of weeks
ago. I've reworked the BAR2 accesses in the way that you had suggested,
which at least for GP10B turned out to be fairly trivial to do. I have
not looked in detail at this for GV11B yet, but a cursory look showed
that BAR2 is accessed in more places, so the
2018 Apr 25
11
[PATCH v2 1/5] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
From: Thierry Reding <treding at nvidia.com>
Depending on the kernel configuration, early ARM architecture setup code
may have attached the GPU to a DMA/IOMMU mapping that transparently uses
the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
backed buffers (a special bit in the GPU's MMU page tables indicates the
memory path to take: via the SMMU or directly to the
2018 Jul 26
8
[RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU
Hello,
There is a trouble on ARM with DMA allocations made by device drivers,
the trouble is that DMA allocations are getting implicitly backed with
IOMMU mapping by the driver core if IOMMU presents in a system and IOMMU
could handle device. This is an undesired behaviour for drivers that
manage IOMMU by themselves, like NVIDIA Tegra GPU driver. On arm32 the
implicit backing happens if