search for: apertur

...ions(-) diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c index 8a0b3bc..6127c28 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)) - in...

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

...ions(-) diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c index 8cd791d..a9192ab 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)) - in...

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

...ouveau/nouveau_fbcon.c index 8e7dc1d..3943a00 100644 --- a/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_devic...

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? > > Signed-off-by: Thierry Reding <treding at nvidia.com> > --- > drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h | 1 +...

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

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 ++- drivers/gpu/drm/nouv...

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

let vga16fb claim 0xA0000+0x10000 region as its aperture; drm drivers don't use it, so we have to detect it and kick vga16fb manually - but only if drm is driving the primary card Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: James Simmons <jsimmons at infradead.org> Cc: Dave Airlie <airlied at redhat.com> Cc: Be...

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 aperture (0) is correct. However, on Tegra the buffers are allocated in system memory, and since the GPU actually cares about the aperture, we need to ensure that the apert...

...his 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 iterate all of the PCI Bar to find the VRAM aperture. 5) It has invented lots of methods to determine which one is the default boot device on a multiple video card coexistence system. But this is still a policy because it doesn't give the user a choice to override. With the observation that device drivers or video aperture helpers may hav...

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

...ouveau_channel_alloc: initialised FIFO 1 [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing fifo 1 [drm] nouveau 0000:01:00.0: Allocating FIFO number 1 [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 1 [TTM] Failed moving buffer. Proposed placement 0x00070004 [TTM] Out of aperture space or DRM memory quota. [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing fifo 1 [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on CRTC 0 and the display is powered off. At this point I need to ssh to the machine as reboot it. If I don't use kms, I can start wmaker just fine: Li...

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

...Component: Driver/nouveau Product: xorg Hi, I will report that when I use BFG Technologies GeForce 7300 GT AGP graphics card (NVIDIA GeForce 7300 GT AGP 512 MB DDR2 SDRAM) on FIC VA-503+ mainboard (VIA Technologies Apollo MVP3 chipset), it will not display text characters when AGP aperture setting is set to 64 MB, 128 MB, or 256 MB settings. If the AGP aperture size is set to 32 MB or less (i.e., 4 MB, 8 MB, 16 MB, and 32 MB), the text characters will get displayed correctly on the screen. The same exact bug has also been observed with EVGA GeForce 6200 AGP graphics card (NVIDIA GeF...

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

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

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 +++ linux-2.6-xen-sparse/arch/...