search for: carveout

...he pollers; > - Re-enable pollers at bits 16 and 0; > - Set pollers address to a proper value. Hey Pierre, This patch is incorrect. As Robert pointed out in an older thread, the registers don't take the physical address of a page, but a somewhat odd "negative offset from the end of carveout". See this example (referring to Robert's last email): 220.926392 read32 #3 +0x00100e10 -> 0x00070000 220.926406 read32 #3 +0x00100e14 -> 0x00010000 carveout_base = 0x70000000 carveout_size = 0x10000000 -- snip -- 223.300495 read32 #3 +0x00100c14 -> 0x00000000 223.30...

...ot/gm20b.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c > @@ -23,39 +23,65 @@ > #include "acr.h" > #include "gm200.h" > > -#define TEGRA210_MC_BASE 0x70019000 > - > #ifdef CONFIG_ARCH_TEGRA > -#define MC_SECURITY_CARVEOUT2_CFG0 0xc58 > -#define MC_SECURITY_CARVEOUT2_BOM_0 0xc5c > -#define MC_SECURITY_CARVEOUT2_BOM_HI_0 0xc60 > -#define MC_SECURITY_CARVEOUT2_SIZE_128K 0xc64 > -#define TEGRA_MC_SECURITY_CARVEOUT_CFG_LOCKED (1 << 1) > /** > * gm2...

Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau_drm.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drm/nouveau_drm.c b/drm/nouveau_drm.c index afb93bb..ffa1e4f 100644 --- a/drm/nouveau_drm.c +++ b/drm/nouveau_drm.c @@ -61,9 +61,10 @@ MODULE_PARM_DESC(debug, "debug string to pass to driver core"); static char

...Skeggs wrote: > > There's some minimal state that needs to be mapped into GPU address space. > > One thing that comes to mind are pushbuffers, which are needed to submit > > stuff to any engine. > I guess you can probably use the start of the kernel's address space > carveout for these kind of mappings actually? It's not like userspace > can ever have virtual addresses there? Yeah. I'm looking into it further, but to answer your original question, I believe there is essentially an address range that nouveau would know about, which it uses for fixed address...

...43122219 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c @@ -23,39 +23,65 @@ #include "acr.h" #include "gm200.h" -#define TEGRA210_MC_BASE 0x70019000 - #ifdef CONFIG_ARCH_TEGRA -#define MC_SECURITY_CARVEOUT2_CFG0 0xc58 -#define MC_SECURITY_CARVEOUT2_BOM_0 0xc5c -#define MC_SECURITY_CARVEOUT2_BOM_HI_0 0xc60 -#define MC_SECURITY_CARVEOUT2_SIZE_128K 0xc64 -#define TEGRA_MC_SECURITY_CARVEOUT_CFG_LOCKED (1 << 1) /** * gm20b_secboot_tegra_read_wpr() - read the WPR registers on Tegra * - * On...

On Tue, Jul 07, 2015 at 08:13:28PM -0400, Ilia Mirkin wrote: > On Tue, Jul 7, 2015 at 8:11 PM, C Bergström <cbergstrom at pathscale.com> wrote: > > On Wed, Jul 8, 2015 at 7:08 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > >> On Tue, Jul 7, 2015 at 8:07 PM, C Bergström <cbergstrom at pathscale.com> wrote: > >>> On Wed, Jul 8, 2015 at 6:58 AM, Ben

...nv_wr32(priv, 0x100c90, impl->trap); Thanks, Pierre > > > > #define NV_PFB_NISO_POLLER_DNISO_BASE_ADR > > 0x00100C18 > > #define NV_PFB_NISO_POLLER_HOSTNB_BASE_ADR > > 0x00100C1C > > #define NV_PFB_NISO_FLUSH_CARVEOUT_ADR > > 0x00100C24 > > > > Each of these should point to at least 32 bytes of otherwise-unused > > FB > > memory, if the poller is enabled. > > > > The proprietary driver enables all three pollers for GPUs that have > > them, wh...

...some minimal state that needs to be mapped into GPU address space. > >> > One thing that comes to mind are pushbuffers, which are needed to submit > >> > stuff to any engine. > >> I guess you can probably use the start of the kernel's address space > >> carveout for these kind of mappings actually? It's not like userspace > >> can ever have virtual addresses there? > > > > Yeah. I'm looking into it further, but to answer your original question, > > I believe there is essentially an address range that nouveau would know...

...uveau/nvkm/subdev/secboot/gm20b.c > > @@ -23,39 +23,65 @@ > > #include "acr.h" > > #include "gm200.h" > > > > -#define TEGRA210_MC_BASE 0x70019000 > > - > > #ifdef CONFIG_ARCH_TEGRA > > -#define MC_SECURITY_CARVEOUT2_CFG0 0xc58 > > -#define MC_SECURITY_CARVEOUT2_BOM_0 0xc5c > > -#define MC_SECURITY_CARVEOUT2_BOM_HI_0 0xc60 > > -#define MC_SECURITY_CARVEOUT2_SIZE_128K 0xc64 > > -#define TEGRA_MC_SECURITY_CARVEOUT_CFG_LOCKED (1 << 1) &g...

(Sending it to the correct Nvidia mailing list, sorry for the spam) Hi, When using acceleration with Nouveau on MacBook Pros with an 9400M (NVAC) card, a PFIFO interrupt 0x00400000 is thrown during the initialisation of that card (sometime after PFIFO and PGRAPH initialisation) and the laptop will lockup [1], forcing users to load Nouveau without acceleration. After some investigation, I found

...100c1c is one of three registers which control the (upper bits of the 32-byte aligned) memory locations that the pollers use: #define NV_PFB_NISO_POLLER_DNISO_BASE_ADR 0x00100C18 #define NV_PFB_NISO_POLLER_HOSTNB_BASE_ADR 0x00100C1C #define NV_PFB_NISO_FLUSH_CARVEOUT_ADR 0x00100C24 Each of these should point to at least 32 bytes of otherwise-unused FB memory, if the poller is enabled. The proprietary driver enables all three pollers for GPUs that have them, when memory is not local (i.e., when using a sysmem carveout rather than dedicat...

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

I don't see this specific case documented anywhere (I also tried to search the r-devel archives, as well as I could); the only close reference mentions NA & FALSE = FALSE, NA | TRUE = TRUE. And there's also this snippet from R-lang: In cases where the result of the operation would be the same for all > possible values the NA could take, the operation may return this value. >

...mapped into GPU address space. > >> >> > One thing that comes to mind are pushbuffers, which are needed to submit > >> >> > stuff to any engine. > >> >> I guess you can probably use the start of the kernel's address space > >> >> carveout for these kind of mappings actually? It's not like userspace > >> >> can ever have virtual addresses there? > >> > > >> > Yeah. I'm looking into it further, but to answer your original question, > >> > I believe there is essentially an ad...

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

...pu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 7bd2e65c2a16c5..6ca9f396e55be4 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -1057,7 +1057,7 @@ void *tegra_drm_alloc(struct tegra_drm *tegra, size_t size, dma_addr_t *dma) *dma = iova_dma_addr(&tegra->carveout.domain, alloc); err = iommu_map(tegra->domain, *dma, virt_to_phys(virt), - size, IOMMU_READ | IOMMU_WRITE); + size, IOMMU_READ | IOMMU_WRITE, GFP_KERNEL); if (err < 0) goto free_iova; diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c index 103fda055394ab..4ddfcd2...

...pu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 7bd2e65c2a16c5..6ca9f396e55be4 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -1057,7 +1057,7 @@ void *tegra_drm_alloc(struct tegra_drm *tegra, size_t size, dma_addr_t *dma) *dma = iova_dma_addr(&tegra->carveout.domain, alloc); err = iommu_map(tegra->domain, *dma, virt_to_phys(virt), - size, IOMMU_READ | IOMMU_WRITE); + size, IOMMU_READ | IOMMU_WRITE, GFP_KERNEL); if (err < 0) goto free_iova; diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c index 103fda055394ab..4ddfcd2...

...pu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 7bd2e65c2a16c5..6ca9f396e55be4 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -1057,7 +1057,7 @@ void *tegra_drm_alloc(struct tegra_drm *tegra, size_t size, dma_addr_t *dma) *dma = iova_dma_addr(&tegra->carveout.domain, alloc); err = iommu_map(tegra->domain, *dma, virt_to_phys(virt), - size, IOMMU_READ | IOMMU_WRITE); + size, IOMMU_READ | IOMMU_WRITE, GFP_KERNEL); if (err < 0) goto free_iova; diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c index 103fda055394ab..4ddfcd2...

iommufd follows the same design as KVM and uses memory cgroups to limit the amount of kernel memory a iommufd file descriptor can pin down. The various internal data structures already use GFP_KERNEL_ACCOUNT to charge its own memory. However, one of the biggest consumers of kernel memory is the IOPTEs stored under the iommu_domain and these allocations are not tracked. This series is the first