search for: apertures

...8 100644 --- a/drivers/gpu/drm/i915/intel_fb.c +++ b/drivers/gpu/drm/i915/intel_fb.c @@ -191,11 +191,16 @@ static int intelfb_create(struct drm_device *dev, uint32_t fb_width, /* setup aperture base/size for vesafb takeover */ - info->aperture_base = dev->mode_config.fb_base; + info->apertures = alloc_apertures(1); + if (!info->apertures) { + ret = -ENOMEM; + goto out_unpin; + } + info->apertures->ranges[0].base = dev->mode_config.fb_base; if (IS_I9XX(dev)) - info->aperture_size = pci_resource_len(dev->pdev, 2); + info->apertures->ranges[0].size = pci_resour...

From: Sui Jingfeng <suijingfeng at loongson.cn> This patch adds the aperture_contain_firmware_fb() function to do the determination. Unfortunately due to the fact that apertures list will be freed dynamically, the location and size information of the firmware fb will be lost after dedicated drivers call aperture_remove_conflicting_devices(), aperture_remove_conflicting_pci_devices() or aperture_remove_all_conflicting_devices() functions We handle this problem by introduci...

...b 100644 --- a/drivers/gpu/drm/i915/intel_fb.c +++ b/drivers/gpu/drm/i915/intel_fb.c @@ -192,11 +192,16 @@ static int intelfb_create(struct drm_device *dev, uint32_t fb_width, /* setup aperture base/size for vesafb takeover */ - info->aperture_base = dev->mode_config.fb_base; + info->apertures = alloc_apertures(1); + if (!info->apertures) { + ret = -ENOMEM; + goto out_unpin; + } + info->apertures->ranges[0].base = dev->mode_config.fb_base; if (IS_I9XX(dev)) - info->aperture_size = pci_resource_len(dev->pdev, 2); + info->apertures->ranges[0].size = pci_resour...

fb_do_apertures_overlap is returning wrong value when one aperture is completely whithin the other. Add generic ranges_overlap macro (probably kernel.h candidate) and use it here. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pj...

.../drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -317,6 +317,9 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t fb_width, info->fix.mmio_len = pci_resource_len(dev->pdev, 1); /* Set aperture base/size for vesafb takeover */ + + info->apertures = alloc_apertures(1); + #if defined(__i386__) || defined(__x86_64__) if (nouveau_fbcon_has_vesafb_or_efifb(dev)) { /* Some NVIDIA VBIOS' are stupid and decide to put the @@ -326,15 +329,15 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t fb_width, * we have left is to find out...

On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The fault information register contains data about the aperture that > caused the failure. This can be useful in debugging aperture related > programming bugs. Should this be parsed for fault buffer entries too? > >

This patch enlarges the PCI GART aperture to 512 MB. The current 64MB aperture is too small and should be enlarged. The optimal amound may be card/system-dependent, so a more sophisticated approach may be preferable. In particular, if RAMIN is less than 1MB, a 512MB aperture won't fit. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_sgdma.c

From: Thierry Reding <treding at nvidia.com> The fault information register contains data about the aperture that caused the failure. This can be useful in debugging aperture related programming bugs. Signed-off-by: Thierry Reding <treding at nvidia.com> --- drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 3 ++-

...drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index ace630a..59641eb 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h @@ -621,6 +621,8 @@ struct drm_nouveau_private { struct { struct dentry *channel_root; } debugfs; + + struct apertures_struct *apertures; }; static inline struct drm_nouveau_private * diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 6b2d5ab..660746b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -194,7 +19...

...es changed, 38 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 3efc339..83c6c6b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -666,11 +666,16 @@ static struct apertures_struct *nouveau_get_apertures(struct drm_device *dev) static int nouveau_remove_conflicting_drivers(struct drm_device *dev) { struct drm_nouveau_private *dev_priv = dev->dev_private; + bool primary = false; dev_priv->apertures = nouveau_get_apertures(dev); if (!dev_priv->apertures)...

From: Thierry Reding <treding at nvidia.com> Hi Ben, these are a couple of patches that are in preparation for adding GV11B support. The fundamental issue that these are trying to solve is that the GV11B is the first Tegra incarnation of the GPU where the aperture really matters. All prior generations would accept any of them. For dGPUs we usually allocate memory in VRAM, so the default

From: Sui Jingfeng <suijingfeng at loongson.cn> Currently, the default VGA device selection is not perfect. Potential problems are: 1) This function is a no-op on non-x86 architectures. 2) It does not take the PCI Bar may get relocated into consideration. 3) It is not effective for the PCI device without a dedicated VRAM Bar. 4) It is device-agnostic, thus it has to waste the effort to

On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The gk20a (as well as all subsequent Tegra instantiations of the GPU) do > in fact use the same apertures as regular GPUs. Prior to gv11b there are > no checks in hardware for the aperture, so we get away with setting VRAM > as the aperture for buffers that are actually in system memory. Can GK20A take comptags with aperture set to system memory? For some reason I can recall, I was under the imp...

Afer an upgrade to xorg-server-1.7.0.902 and latest git for the kernel and xorg nouveau drivers I cannot start x with kms under wmaker. As root (just twm and an xterm) it's ok. Dmesg shows: [drm] DAC-6: set mode 1680x1050 1a [drm] nouveau 0000:01:00.0: nv04_dac_mode_set called for encoder 0 [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on CRTC 0 [drm] nouveau 0000:01:00.0: Setting dpms

...eggs wrote: > On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > > > From: Thierry Reding <treding at nvidia.com> > > > > The gk20a (as well as all subsequent Tegra instantiations of the GPU) do > > in fact use the same apertures as regular GPUs. Prior to gv11b there are > > no checks in hardware for the aperture, so we get away with setting VRAM > > as the aperture for buffers that are actually in system memory. > Can GK20A take comptags with aperture set to system memory? For some > reason I can recall,...

https://bugs.freedesktop.org/show_bug.cgi?id=63101 Priority: medium Bug ID: 63101 Assignee: nouveau at lists.freedesktop.org Summary: [Ubuntu 10.04.4 LTS 32-bit] NVIDIA GeForce 7300 GT AGP graphics card will not display any text characters on VIA Technologies Apollo MVP3-based mainboard QA Contact:

From: Thierry Reding <treding at nvidia.com> The gk20a (as well as all subsequent Tegra instantiations of the GPU) do in fact use the same apertures as regular GPUs. Prior to gv11b there are no checks in hardware for the aperture, so we get away with setting VRAM as the aperture for buffers that are actually in system memory. Signed-off-by: Thierry Reding <treding at nvidia.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h |...

Changes in v2: - Compute size based on ramin_rsvd_size This patch enlarges the PCI GART aperture to 512 MB, or the space covered by a DMA object filling half RAMIN. The current 64MB aperture is too small and should be enlarged. The optimal amound may be card/system-dependent, so a more sophisticated approach may be preferable. Could anyone with an nv04 test whether this doesn't break there?

http://bugs.freedesktop.org/show_bug.cgi?id=24810 Summary: TTM out of aperture space, X lockup Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

These are the diffs against the pristine versions of arch/x86_64/kernel/[aperture.c,pci-gart.c] to better show the changes necessary to adapt those files to Xen. They were included with the patch and should not be applied again. -Mark Langsdorf AMD, Inc. --- pristine-linux-2.6.12/arch/x86_64/kernel/aperture.c 2005-06-17 12:48:29.000000000 -0700 +++