search for: nvkm_device_tegra_new

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. &g...

...tem memory, i.e., when all RAM is > 4 GB. > + */ > + dma_set_mask_and_coherent(device->dev, > + DMA_BIT_MASK(device->mmu->dma_bits)); I would just move this to nvkm_device_pci_new() so that it perfectly mirrors the same call done in nvkm_device_tegra_new(), which was done for the same purpose. Otherwise, looks good to me.

...+ struct clk *clk_ref; struct clk *clk_pwr; struct regulator *vdd; @@ -36,6 +37,10 @@ struct nvkm_device_tegra_func { * bypassed). A value of 0 means an IOMMU is never used. */ u8 iommu_bit; + /* + * Whether the chip requires a reference clock + */ + bool require_ref_clk; }; int nvkm_device_tegra_new(const struct nvkm_device_tegra_func *, diff --git a/drm/nouveau/nouveau_platform.c b/drm/nouveau/nouveau_platform.c index 2dfe58af12e4..4c4cc2260257 100644 --- a/drm/nouveau/nouveau_platform.c +++ b/drm/nouveau/nouveau_platform.c @@ -55,6 +55,11 @@ static const struct nvkm_device_tegra_func gk20a_p...

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> ---

...struct platform_device *pdev, > struct nvkm_device **pdevice) > { > - struct drm_device *drm; > + struct nouveau_drm *nv_dev; > + struct drm_device *drm_dev; > int err; > > err = nvkm_device_tegra_new(func, pdev, nouveau_config, nouveau_debug, > @@ -1293,22 +1288,21 @@ nouveau_platform_device_create(const struct nvkm_device_tegra_func *func, > if (err) > goto err_free; > > - drm = drm_dev_alloc(&driver_platform, &pdev->dev); > - if...

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. Signed-off-by: Alexandre C...

On Wed, Jan 27, 2016 at 5:44 AM, Lucas Stach <dev at lynxeye.de> wrote: > 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 >> devic...

...tegra.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drm/nouveau/nvkm/engine/device/tegra.c b/drm/nouveau/nvkm/engine/device/tegra.c index 6d89416f0bc1..e1cd665aee2c 100644 --- a/drm/nouveau/nvkm/engine/device/tegra.c +++ b/drm/nouveau/nvkm/engine/device/tegra.c @@ -272,6 +272,15 @@ nvkm_device_tegra_new(const struct nvkm_device_tegra_func *func, if (IS_ERR(tdev->clk_pwr)) return PTR_ERR(tdev->clk_pwr); + /** + * The IOMMU bit defines the upper limit of the GPU-addressable space. + * This will be refined in nouveau_ttm_init but we need to do it early + * for instmem to behave proper...

...on(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c index 189ed80e21ffb..ac5d4cf058c25 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c @@ -282,7 +282,7 @@ nvkm_device_tegra_new(const struct nvkm_device_tegra_func *func, } } - tdev->rst = devm_reset_control_get(&pdev->dev, "gpu"); + tdev->rst = devm_reset_control_get_exclusive(&pdev->dev, "gpu"); if (IS_ERR(tdev->rst)) { ret = PTR_ERR(tdev->rst); goto free; -- 2...

...t; [ 12.050710] x1 : ffff8001c915b800 x0 : 0000000000000000 > [ 12.050713] Process systemd-udevd (pid: 261, stack limit = > 0x00000000247b2b64) > [ 12.050714] Call trace: > [ 12.050717] mutex_lock+0x28/0x58 > [ 12.050721] iommu_attach_device+0xac/0xf8 > [ 12.050948] nvkm_device_tegra_new+0x260/0x510 [nouveau] > [ 12.051166] nouveau_platform_device_create+0x48/0xa8 [nouveau] > [ 12.051364] nouveau_platform_probe+0x34/0x80 [nouveau] > [ 12.051368] platform_drv_probe+0x60/0xc0 > [ 12.051372] driver_probe_device+0x33c/0x4a0 > [ 12.051375] __driver_attach+0...

...vice); } @@ -1285,7 +1279,8 @@ nouveau_platform_device_create(const struct nvkm_device_tegra_func *func, struct platform_device *pdev, struct nvkm_device **pdevice) { - struct drm_device *drm; + struct nouveau_drm *nv_dev; + struct drm_device *drm_dev; int err; err = nvkm_device_tegra_new(func, pdev, nouveau_config, nouveau_debug, @@ -1293,22 +1288,21 @@ nouveau_platform_device_create(const struct nvkm_device_tegra_func *func, if (err) goto err_free; - drm = drm_dev_alloc(&driver_platform, &pdev->dev); - if (IS_ERR(drm)) { - err = PTR_ERR(drm); + nv_dev = devm_drm...

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

...0000000004 x2 : 0000000000000000 [ 12.050710] x1 : ffff8001c915b800 x0 : 0000000000000000 [ 12.050713] Process systemd-udevd (pid: 261, stack limit = 0x00000000247b2b64) [ 12.050714] Call trace: [ 12.050717] mutex_lock+0x28/0x58 [ 12.050721] iommu_attach_device+0xac/0xf8 [ 12.050948] nvkm_device_tegra_new+0x260/0x510 [nouveau] [ 12.051166] nouveau_platform_device_create+0x48/0xa8 [nouveau] [ 12.051364] nouveau_platform_probe+0x34/0x80 [nouveau] [ 12.051368] platform_drv_probe+0x60/0xc0 [ 12.051372] driver_probe_device+0x33c/0x4a0 [ 12.051375] __driver_attach+0xdc/0x128 [ 12.051377]...

This v4 is now a 3 piece series, after Alexandre pointed out that both GF 100 and NV50 are affected by the same issue, and that a related issue has been solved already for Tegra in commit 9d0394c6bed5 ("drm/nouveau/instmem/gk20a: set DMA mask early"). The issue that this series addresses is the fact that the Nouveau driver invokes the DMA API before setting the DMA mask. In both cases

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

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

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

Hi folks, Currently, when the device is removed (or the driver is unbound) the nouveau_drm structure de-allocated. However, it's still accessible from and used by some DRM layer callbacks. For example, file handles can be closed after the device has been removed (physically or otherwise). This series converts the Nouveau device structure to be allocated and de-allocated with the

GP10B is the chip used in Tegra X2 SoCs. This patchset adds support for its base engines after reworking secboot a bit to accomodate its calling convention better. This patchset has been tested rendering simple off-screen buffers using Mesa and yielded the expected result. Alexandre Courbot (15): secboot: allow to boot multiple falcons secboot: pass instance to LS firmware loaders secboot:

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