<p dir="ltr">On 18 Feb 2015 17:08, "Alexandre Courbot" <<a href="mailto:gnurou@gmail.com">gnurou@gmail.com</a>> wrote:<br>
><br>
> On Wed, Feb 18, 2015 at 8:01 AM, Ben Skeggs <<a href="mailto:skeggsb@gmail.com">skeggsb@gmail.com</a>> wrote:<br>
> > On Tue, Feb 17, 2015 at 5:47 PM, Alexandre Courbot <<a href="mailto:acourbot@nvidia.com">acourbot@nvidia.com</a>> wrote:<br>
> >> Having a RAM device does not make sense for chips like GK20A which have<br>
> >> no dedicated video memory. The dummy RAM device that we used so far<br>
> >> works as a temporary band-aid, but in the long-term it is desirable for<br>
> >> the driver to be able to work without any kind of VRAM.<br>
> >><br>
> >> This patch adds a few conditionals in places where a RAM device was<br>
> >> assumed to be present and allows some more objects to be allocated from<br>
> >> the TT domain, allowing Nouveau to handle GPUs for which<br>
> >> pfb->ram == NULL.<br>
> >><br>
> >> Signed-off-by: Alexandre Courbot <<a href="mailto:acourbot@nvidia.com">acourbot@nvidia.com</a>><br>
> >> ---<br>
> >> drm/nouveau/nouveau_display.c | 8 +++++++-<br>
> >> drm/nouveau/nouveau_ttm.c | 3 +++<br>
> >> drm/nouveau/nv84_fence.c | 14 +++++++++++---<br>
> >> drm/nouveau/nvkm/engine/device/base.c | 9 ++++++---<br>
> >> drm/nouveau/nvkm/subdev/clk/base.c | 2 +-<br>
> >> drm/nouveau/nvkm/subdev/fb/base.c | 26 ++++++++++++++++++--------<br>
> >> drm/nouveau/nvkm/subdev/ltc/gf100.c | 10 +++++++++-<br>
> >> 7 files changed, 55 insertions(+), 17 deletions(-)<br>
> >><br>
> >> diff --git a/drm/nouveau/nouveau_display.c b/drm/nouveau/nouveau_display.c<br>
> >> index 860b0e2d4181..68ee0af22eea 100644<br>
> >> --- a/drm/nouveau/nouveau_display.c<br>
> >> +++ b/drm/nouveau/nouveau_display.c<br>
> >> @@ -869,13 +869,19 @@ nouveau_display_dumb_create(struct drm_file *file_priv, struct drm_device *dev,<br>
> >> struct drm_mode_create_dumb *args)<br>
> >> {<br>
> >> struct nouveau_bo *bo;<br>
> >> + uint32_t domain;<br>
> >> int ret;<br>
> >><br>
> >> args->pitch = roundup(args->width * (args->bpp / 8), 256);<br>
> >> args->size = args->pitch * args->height;<br>
> >> args->size = roundup(args->size, PAGE_SIZE);<br>
> >><br>
> >> - ret = nouveau_gem_new(dev, args->size, 0, NOUVEAU_GEM_DOMAIN_VRAM, 0, 0, &bo);<br>
> >> + if (nvxx_fb(&nouveau_drm(dev)->device)->ram)<br>
> > For these checks in the drm, it's probably better to use<br>
> > nouveau_drm(dev)->device.info.ram_size.<br>
><br>
> I wonder - in other places (e.g. clock, ltc) we don't have access to<br>
> nouveau_drm, so IIUC we need to rely on pfb->ram there. <br>
Correct. </p>
<p dir="ltr">>Wouldn't it be<br>
> more confusing to use two different ways to check the presence of VRAM<br>
> when we could stick to a single one?<br>
It's best to think of nvkm/ as a separate entity, and it will be at some point (drm load on its own, inside a vm), and drm might not be able to access it's internal structures.</p>
<p dir="ltr">That's not the case now, so the code is fine as-is for the moment. But it's worth keeping in mind. </p>
<p dir="ltr">Thanks, <br>
Ben. <br>
</p>