From patchwork Mon May 26 09:58:18 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexandre Courbot X-Patchwork-Id: 4245821 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id B1E289F32B for ; Tue, 27 May 2014 01:25:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E4E852012B for ; Tue, 27 May 2014 01:25:55 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 2E37820034 for ; Tue, 27 May 2014 01:25:55 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6C5E26E60F; Mon, 26 May 2014 18:25:40 -0700 (PDT) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 2C8CC6E427; Mon, 26 May 2014 02:58:40 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id ik5so5582872vcb.31 for ; Mon, 26 May 2014 02:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kqtnvm7QgbO18Gqc1vP4uknW0nkd7ipZK7hUrPNEQEY=; b=Lm5bxJXesKugKGiRMF2uzLRoyyLxD+of8RneXpMzlYwIUu6bV1jrooc7KR2PAK813Y BpoddBoTLPYyi/xXedbPXRQTf3nhu8Y+DPje/T5EvycJ2NCHbisE2QDjfp0I3l+dmgmL y19htyIkYSsGPxGySSwtS0jSne2g7G7HRQ6K00ji8LxinnkhC/htfjmvurqjkPgZKipR MOoCLqVHsS8AAW9o7M4h33UgkMMU4XoWQHWr18hiEpE/hTu9DbW2iuetIh7t4IyVzBrs mNTId07PgLZ0dw+l6p4Ghwxzg8aRK0WZFkUHml50vj6x6xwUJ3MixrBWup0Ert8bkTX0 KmcA== X-Received: by 10.52.147.170 with SMTP id tl10mr17307029vdb.14.1401098318398; Mon, 26 May 2014 02:58:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.190.170 with HTTP; Mon, 26 May 2014 02:58:18 -0700 (PDT) In-Reply-To: <1400837055.4921.4.camel@weser.hi.pengutronix.de> References: <1400492771-9746-1-git-send-email-acourbot@nvidia.com> <1400493433.8467.24.camel@weser.hi.pengutronix.de> <5379D7A0.3050509@nvidia.com> <1400494582.8467.28.camel@weser.hi.pengutronix.de> <1400837055.4921.4.camel@weser.hi.pengutronix.de> From: Alexandre Courbot Date: Mon, 26 May 2014 18:58:18 +0900 Message-ID: Subject: Re: [RFC] drm/nouveau: disable caching for VRAM BOs on ARM To: Lucas Stach X-Mailman-Approved-At: Mon, 26 May 2014 18:25:37 -0700 Cc: Stephen Warren , "nouveau@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Ben Skeggs , "linux-tegra@vger.kernel.org" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, May 23, 2014 at 6:24 PM, Lucas Stach wrote: >> The best way to solve this issue would be to not use the BAR at all >> since the memory behind these objects can be directly accessed by the >> CPU. As such it would better be mapped using ttm_bo_kmap_ttm() >> instead. But right now this is clearly not how nouveau_bo.c is written >> and it does not look like this can easily be done. :/ > > Yeah, it sounds like we want this shortcut for stolen VRAM > implementations. Tried playing a bit with nouveau_bo and the following hack allows a simple Mesa program to run to completion... once (second time leads to a kernel panic): man->io_reserve_fastpath = false; @@ -556,6 +555,7 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type, man->default_caching = TTM_PL_FLAG_WC; #endif break; + case TTM_PL_VRAM: case TTM_PL_TT: if (nv_device(drm->device)->card_type >= NV_50) man->func = &nouveau_gart_manager; @@ -1297,6 +1297,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem) break; /* fallthrough, tiled memory */ case TTM_PL_VRAM: + break; mem->bus.offset = mem->start << PAGE_SHIFT; mem->bus.base = nv_device_resource_start(nouveau_dev(dev), 1); mem->bus.is_iomem = true; Of course it won't go very far this way, but I wonder if the principle is not what we would want to do for UMA devices? Not using the vram manager at all, and strictly rely on TT placements for BOs. We will need to add extra handling for things like tiled memory. Does that look like the right direction? diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index f00ae18003f1..6317d30a8e1d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -538,7 +538,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type, man->available_caching = TTM_PL_MASK_CACHING; man->default_caching = TTM_PL_FLAG_CACHED; break; - case TTM_PL_VRAM: if (nv_device(drm->device)->card_type >= NV_50) { man->func = &nouveau_vram_manager;