lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 02 Feb 2014 00:58:26 +0100
From:	Lucas Stach <dev@...xeye.de>
To:	Ilia Mirkin <imirkin@...m.mit.edu>
Cc:	Alexandre Courbot <acourbot@...dia.com>,
	Ben Skeggs <bskeggs@...hat.com>,
	"nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	gnurou@...il.com, Eric Brower <ebrower@...dia.com>,
	Stephen Warren <swarren@...dotorg.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-tegra@...r.kernel.org,
	Terje Bergstrom <tbergstrom@...dia.com>,
	Ken Adams <KAdams@...dia.com>
Subject: Re: [RFC 14/16] drm/nouveau/fb: add GK20A support

Am Samstag, den 01.02.2014, 18:28 -0500 schrieb Ilia Mirkin:
> On Sat, Feb 1, 2014 at 8:40 AM, Lucas Stach <dev@...xeye.de> wrote:
> > Am Samstag, den 01.02.2014, 12:16 +0900 schrieb Alexandre Courbot:
> >> Add a clumsy-but-working FB support for GK20A. This chip only uses system
> >> memory, so we allocate a big chunk using CMA and let the existing memory
> >> managers work on it.
> >>
> >> A better future design would be to allocate objects directly from system
> >> memory without having to suffer from the limitations of a large,
> >> contiguous pool.
> >>
> > I don't know if Tegra124 is similar to 114 in this regard [hint: get the
> > TRM out :)], but if you go for a dedicated VRAM allocator, wouldn't it
> > make sense to take a chunk of the MMIO overlaid memory for this when
> > possible, rather than carving this out of CPU accessible mem?
> 
> This is probably a stupid question... what do you need VRAM for
> anyways? In _theory_ it's an abstraction to talk about memory that's
> not accessible by the CPU. This is obviously not the case here, and
> presumably the GPU can access all the memory in the system, so it can
> be all treated as "GART" memory... AFAIK all accesses are behind the
> in-GPU MMU, so contiguous physical memory isn't an issue either. In
> practice, I suspect nouveau automatically sticks certain things into
> vram (gpuobj's), but it should be feasible to make them optionally use
> GART memory when VRAM is not available. I haven't really looked at the
> details though, perhaps that's a major undertaking.
> 
>   -ilia
> 
If it's similar to the Tegar114 there actually is memory that isn't
accessible from the CPU. About 2GB of the address space is overlaid with
MMIO for the devices, so in a 4GB system you potentially have 2GB of RAM
that's only visible for the devices.

But yes in general nouveau should just fall back to a GART placement if
VRAM isn't available.

> >
> >> Signed-off-by: Alexandre Courbot <acourbot@...dia.com>
> >> ---
> >>  drivers/gpu/drm/nouveau/Makefile                 |  2 +
> >>  drivers/gpu/drm/nouveau/core/include/subdev/fb.h |  1 +
> >>  drivers/gpu/drm/nouveau/core/subdev/fb/nvea.c    | 28 ++++++++++
> >>  drivers/gpu/drm/nouveau/core/subdev/fb/priv.h    |  1 +
> >>  drivers/gpu/drm/nouveau/core/subdev/fb/ramnvea.c | 67 ++++++++++++++++++++++++
> >>  5 files changed, 99 insertions(+)
> >>  create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/nvea.c
> >>  create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/ramnvea.c
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
> >> index 3548fcd..d9fe3e6 100644
> >> --- a/drivers/gpu/drm/nouveau/Makefile
> >> +++ b/drivers/gpu/drm/nouveau/Makefile
> >> @@ -100,6 +100,7 @@ nouveau-y += core/subdev/fb/nvaa.o
> >>  nouveau-y += core/subdev/fb/nvaf.o
> >>  nouveau-y += core/subdev/fb/nvc0.o
> >>  nouveau-y += core/subdev/fb/nve0.o
> >> +nouveau-y += core/subdev/fb/nvea.o
> >>  nouveau-y += core/subdev/fb/ramnv04.o
> >>  nouveau-y += core/subdev/fb/ramnv10.o
> >>  nouveau-y += core/subdev/fb/ramnv1a.o
> >> @@ -114,6 +115,7 @@ nouveau-y += core/subdev/fb/ramnva3.o
> >>  nouveau-y += core/subdev/fb/ramnvaa.o
> >>  nouveau-y += core/subdev/fb/ramnvc0.o
> >>  nouveau-y += core/subdev/fb/ramnve0.o
> >> +nouveau-y += core/subdev/fb/ramnvea.o
> >>  nouveau-y += core/subdev/fb/sddr3.o
> >>  nouveau-y += core/subdev/fb/gddr5.o
> >>  nouveau-y += core/subdev/gpio/base.o
> >> diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/fb.h b/drivers/gpu/drm/nouveau/core/include/subdev/fb.h
> >> index d7ecafb..3905816 100644
> >> --- a/drivers/gpu/drm/nouveau/core/include/subdev/fb.h
> >> +++ b/drivers/gpu/drm/nouveau/core/include/subdev/fb.h
> >> @@ -105,6 +105,7 @@ extern struct nouveau_oclass *nvaa_fb_oclass;
> >>  extern struct nouveau_oclass *nvaf_fb_oclass;
> >>  extern struct nouveau_oclass *nvc0_fb_oclass;
> >>  extern struct nouveau_oclass *nve0_fb_oclass;
> >> +extern struct nouveau_oclass *nvea_fb_oclass;
> >>
> >>  #include <subdev/bios/ramcfg.h>
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/nvea.c b/drivers/gpu/drm/nouveau/core/subdev/fb/nvea.c
> >> new file mode 100644
> >> index 0000000..5ff6029
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/nouveau/core/subdev/fb/nvea.c
> >> @@ -0,0 +1,28 @@
> >> +/*
> >> + * Copyright (c) 2014, NVIDIA Corporation. All rights reserved.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify it
> >> + * under the terms and conditions of the GNU General Public License,
> >> + * version 2, as published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope it will be useful, but WITHOUT
> >> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> >> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> >> + * more details.
> >> + *
> >> + */
> >> +
> >> +#include "nvc0.h"
> >> +
> >> +struct nouveau_oclass *
> >> +nvea_fb_oclass = &(struct nouveau_fb_impl) {
> >> +     .base.handle = NV_SUBDEV(FB, 0xea),
> >> +     .base.ofuncs = &(struct nouveau_ofuncs) {
> >> +             .ctor = nvc0_fb_ctor,
> >> +             .dtor = nvc0_fb_dtor,
> >> +             .init = nvc0_fb_init,
> >> +             .fini = _nouveau_fb_fini,
> >> +     },
> >> +     .memtype = nvc0_fb_memtype_valid,
> >> +     .ram = &nvea_ram_oclass,
> >> +}.base;
> >> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/priv.h b/drivers/gpu/drm/nouveau/core/subdev/fb/priv.h
> >> index edaf95d..0b95a25 100644
> >> --- a/drivers/gpu/drm/nouveau/core/subdev/fb/priv.h
> >> +++ b/drivers/gpu/drm/nouveau/core/subdev/fb/priv.h
> >> @@ -32,6 +32,7 @@ extern struct nouveau_oclass nva3_ram_oclass;
> >>  extern struct nouveau_oclass nvaa_ram_oclass;
> >>  extern struct nouveau_oclass nvc0_ram_oclass;
> >>  extern struct nouveau_oclass nve0_ram_oclass;
> >> +extern struct nouveau_oclass nvea_ram_oclass;
> >>
> >>  int nouveau_sddr3_calc(struct nouveau_ram *ram);
> >>  int nouveau_gddr5_calc(struct nouveau_ram *ram, bool nuts);
> >> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvea.c b/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvea.c
> >> new file mode 100644
> >> index 0000000..3038e08
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/nouveau/core/subdev/fb/ramnvea.c
> >> @@ -0,0 +1,67 @@
> >> +/*
> >> + * Copyright (c) 2014, NVIDIA Corporation. All rights reserved.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify it
> >> + * under the terms and conditions of the GNU General Public License,
> >> + * version 2, as published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope it will be useful, but WITHOUT
> >> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> >> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> >> + * more details.
> >> + *
> >> + */
> >> +
> >> +/*
> >> + * TODO replace this CMA-requiring horror with a proper allocator for GPU
> >> + * objects in main memory. But for the moment it does the job and can reuse some
> >> + * of the nvc0 functions.
> >> + */
> >> +
> >> +#include "nvc0.h"
> >> +
> >> +#include <linux/dma-mapping.h>
> >> +
> >> +static int
> >> +nvea_ram_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
> >> +           struct nouveau_oclass *oclass, void *data, u32 datasize,
> >> +           struct nouveau_object **pobject)
> >> +{
> >> +     struct nouveau_fb *pfb = nouveau_fb(parent);
> >> +     struct nouveau_ram *ram;
> >> +     void *vram;
> >> +     dma_addr_t dma_handle;
> >> +     int ret;
> >> +
> >> +     ret = nouveau_ram_create(parent, engine, oclass, &ram);
> >> +     *pobject = nv_object(ram);
> >> +     if (ret)
> >> +             return ret;
> >> +
> >> +     ram->type   = NV_MEM_TYPE_STOLEN;
> >> +     /* Use a fixed size of 64MB for now */
> >> +     ram->size = 0x4000000;
> >> +     ram->stolen = (u64)0x00000000;
> >> +     vram = dma_alloc_coherent(nv_device_base(nv_device(parent)), ram->size,
> >> +                               &dma_handle, GFP_KERNEL);
> >> +     if (!vram)
> >> +             return -ENOMEM;
> >> +
> >> +     ret = nouveau_mm_init(&pfb->vram, dma_handle >> 12, ram->size >> 12, 1);
> >> +     if (ret)
> >> +             return ret;
> >> +
> >> +     ram->get = nvc0_ram_get;
> >> +     ram->put = nvc0_ram_put;
> >> +     return 0;
> >> +}
> >> +
> >> +struct nouveau_oclass
> >> +nvea_ram_oclass = {
> >> +     .ofuncs = &(struct nouveau_ofuncs) {
> >> +             .ctor = nvea_ram_ctor,
> >> +             .dtor = _nouveau_ram_dtor,
> >> +             .init = _nouveau_ram_init,
> >> +             .fini = _nouveau_ram_fini,
> >> +     },
> >> +};
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists