similar to: [RFC PATCH] drm/nouveau: use vmalloc for pgt allocation

Op 05-03-13 19:57, Marcin Slusarz schreef: > Page tables on nv50 take 48kB, which can be hard to allocate in one piece. > Let's use vmalloc. > > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > Cc: stable at vger.kernel.org [3.7+] > --- > drivers/gpu/drm/nouveau/core/subdev/vm/base.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) >

On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote: > I think I found at least two cases where "12" was used where it should > have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This > is only the tip of the iceberg, so this isn't a formal patch submission, > but I would appreciate your thought as to whether the below is correct > (and thus

On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote: > > diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c > > index 5c7433d..c314a5f 100644 > > --- a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c > > +++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c > > @@ -190,8 +190,8 @@

On Thu, 2013-08-29 at 16:49 +1000, Ben Skeggs wrote: > > Additionally the current code is broken in that the upper layer in > > vm/base.c doesn't increment "pte" by the right amount. > > > > Now, if those two assertions can be made always true: > > > > - Those two functions (map_sg and map_sg_table) never deal with the > > "big"

Op 11-08-13 07:36, Benjamin Herrenschmidt schreef: > On Sun, 2013-08-11 at 10:41 +1000, Benjamin Herrenschmidt wrote: >> Now, to do that, I need a better understanding of the various things >> in there since I'm not familiar with nouveau at all. What I think I've >> figured out is with a few questions, it would be awesome if you could >> answer them so I can have

Hi, Generally the the imported buffers which has memory type TTM_PL_TT are mapped as small pages probably due to lack of big page allocation. But the platform device which also use memory type TTM_PL_TT, like GK20A, can *allocate* big page though the IOMMU hardware inside the SoC. This is a try to map the imported buffers as big pages in GMMU by the platform IOMMU. With some preparation work to

Op 11-08-13 10:04, Benjamin Herrenschmidt schreef: > On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote: > >> I think I found at least two cases where "12" was used where it should >> have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This >> is only the tip of the iceberg, so this isn't a formal patch submission, >> but I would

The refcount was not protected by the vm lock, fix this.. ------------[ cut here ]------------ WARNING: CPU: 2 PID: 2008 at drivers/gpu/drm/nouveau/core/core/mm.c:242 nouveau_mm_fini+0x4f/0x56 [nouveau]() Modules linked in: adt7475 ebtable_nat ebtables nouveau ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle bridge stp llc snd_hda_codec_hdmi kvm_intel ttm kvm

On Sun, Aug 11, 2013 at 7:35 PM, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote: > On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote: > >> > diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c >> > index 5c7433d..c314a5f 100644 >> > ---

Hi folks ! So I've been trying to figure out what it would take to make nouveau work properly on architectures where PAGE_SIZE isn't 4k such as most ppc64's. An initial patch from Dave fixed a bogon in nv41.c nv41_vm_map_sg() which was trying to handle the case at that low level, but this isn't enough, and after a bit of digging, I also think that's not the right approach:

On Fri, Nov 29, 2013 at 4:01 PM, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote: > On Thu, 2013-08-29 at 16:49 +1000, Ben Skeggs wrote: > >> > Additionally the current code is broken in that the upper layer in >> > vm/base.c doesn't increment "pte" by the right amount. >> > >> > Now, if those two assertions can be made

Hello, My system died last night apparently due to OOM conditions. Note that I don't have any swap set up, but my understanding is that this is not required. The full log is at: http://pastebin.com/YCYUXWvV. It was in my messages, so I guess the system took a bit to die completely. nouveau is somewhat implicated, as it is the first thing that hits an allocation failure in nouveau_vm_create,

Hello Han, I am pleased you approve of the design and implementation of the XI shadow mechanism. And I appreciate the time and care you''ve taken in reviewing this substantial body of new code. You asked about performance statistics. With the current XI patch, we are seeing the following: - page faults times for XI are about 4 times faster than non-XI: 10.56 (non-XI) vs 2.43

When I list a directory within the linux OS, appears like this: ... -rwxr--r--. 1 root pgt.cxt 7,2K Nov 25 14:33 New Text OpenDocument.odt ... At smb.conf is of this way: [global] workgroup = PGT server string = Descricao security = DOMAIN obey pam restrictions = Yes ... registry shares = Yes idmap uid = 1000-20000 idmap gid = 1000-20000

On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Adapt the NVC0 BAR driver to make it able to support chips that do not > expose a BAR3. When this happens, BAR1 is then used for USERD mapping > and the BAR alloc() functions is disabled, making GPU objects unable > to rely on BAR for data access and falling back to PRAMIN. > >

On Sat, Apr 18, 2015 at 12:37 AM, Terje Bergstrom <tbergstrom at nvidia.com> wrote: > > On 04/17/2015 02:11 AM, Alexandre Courbot wrote: >> >> Tracking the PDE and PTE of each memory chunk can probably be avoided >> if you change your unmapping strategy. Currently you are going through >> the list of nvkm_vm_bp_list, but you know your PDE and PTE are always

Hi, Robert, I found out another confusing code snippet: in void xi_invl_mfn(struct domain *d, unsigned long mfn) if (ext && pfn < ext->large_page_aligned_size) According to the code, it should be if (ext && (pfn>>SPT_ENTRIES_ORDER) < ext->large_page_aligned_size) If I made any mistake, please point it out.

Most graphics cards nowadays have a multiple of this limit as their vram, so limiting GART doesn't seem to make much sense. Signed-off-by: Maarten >Lnkhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index 3a5e19a..41ddecd 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c +++

On Sun, 2013-08-11 at 10:41 +1000, Benjamin Herrenschmidt wrote: > Now, to do that, I need a better understanding of the various things > in there since I'm not familiar with nouveau at all. What I think I've > figured out is with a few questions, it would be awesome if you could > answer them so I can have a shot at fixing it all :-) Ok, a few more questions :-) - in struct

Hello everyone, GK20A is the Kepler-based GPU used in the upcoming Tegra K1 chips. The following patches perform architectural changes to Nouveau that are necessary to support non-PCI GPUs and add initial support for GK20A. Although the support is still very basic and more user-space changes will be needed to make the full graphics stack run on top of it, we were able to successfully open