From patchwork Tue Dec 5 09:32:23 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alexey Brodkin X-Patchwork-Id: 10095075 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 16AC760327 for ; Wed, 6 Dec 2017 08:39:29 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0823A29C10 for ; Wed, 6 Dec 2017 08:39:29 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F16C529C13; Wed, 6 Dec 2017 08:39:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 5A2A729C10 for ; Wed, 6 Dec 2017 08:39:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 065586E6BE; Wed, 6 Dec 2017 08:38:51 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from smtprelay.synopsys.com (smtprelay.synopsys.com [198.182.60.111]) by gabe.freedesktop.org (Postfix) with ESMTPS id D4B3889C80 for ; Tue, 5 Dec 2017 09:32:27 +0000 (UTC) Received: from mailhost.synopsys.com (mailhost1.synopsys.com [10.12.238.239]) by smtprelay.synopsys.com (Postfix) with ESMTP id 17E1E10C1299; Tue, 5 Dec 2017 01:32:27 -0800 (PST) Received: from mailhost.synopsys.com (localhost [127.0.0.1]) by mailhost.synopsys.com (Postfix) with ESMTP id F3483F62; Tue, 5 Dec 2017 01:32:26 -0800 (PST) Received: from US01WXQAHTC1.internal.synopsys.com (us01wxqahtc1.internal.synopsys.com [10.12.238.230]) by mailhost.synopsys.com (Postfix) with ESMTP id DFDB4F61; Tue, 5 Dec 2017 01:32:26 -0800 (PST) Received: from DE02WEHTCB.internal.synopsys.com (10.225.19.28) by US01WXQAHTC1.internal.synopsys.com (10.12.238.230) with Microsoft SMTP Server (TLS) id 14.3.266.1; Tue, 5 Dec 2017 01:32:25 -0800 Received: from DE02WEMBXB.internal.synopsys.com ([fe80::95ce:118a:8321:a099]) by DE02WEHTCB.internal.synopsys.com ([::1]) with mapi id 14.03.0266.001; Tue, 5 Dec 2017 10:32:23 +0100 From: Alexey Brodkin To: "l.stach@pengutronix.de" Subject: Re: etnaviv: PHYS_OFFSET usage Thread-Topic: etnaviv: PHYS_OFFSET usage Thread-Index: AQHTXi4spoJ0e8C7UEu4/AJubzp4EaMVlMOAgAAOrYCAAAWFAIAe4dIA Date: Tue, 5 Dec 2017 09:32:23 +0000 Message-ID: <1512466342.4977.77.camel@synopsys.com> References: <1510763053.29843.64.camel@synopsys.com> <1510764243.2835.13.camel@pengutronix.de> <1510767395.29843.83.camel@synopsys.com> <1510768580.2835.15.camel@pengutronix.de> In-Reply-To: <1510768580.2835.15.camel@pengutronix.de> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.225.15.245] Content-ID: MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 06 Dec 2017 08:38:48 +0000 Cc: "linux-snps-arc@lists.infradead.org" , "Vineet.Gupta1@synopsys.com" , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 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-Virus-Scanned: ClamAV using ClamSMTP Hi Lucas, On Wed, 2017-11-15 at 18:56 +0100, Lucas Stach wrote: > Am Mittwoch, den 15.11.2017, 17:36 +0000 schrieb Alexey Brodkin: [snip] > I'm not keen on having a private memory region for the GPU. Normally we > just use the shared system CMA memory region (and we will point the > linear memory window there on MC2.0 GPUs), which has the added benefit > that we can map the contiguous framebuffers allocated by another device > through the linear window, which is a crucial performance optimization > for the MMUv1 GPUs. > > The only time where we really need to know the start of RAM is on MC1.0 > GPUs which have a hardware bug in the TS unit, so we try to avoid > moving the linear window at all to work around that. In that case the > PHYS_OFFSET check is really there to avoid the situation where the > linear window would not allow any RAM to be reached at all. Then we > need to move the window, but disable any TS functionality, impacting > performance a lot. Thanks a lot fro explanation! > As MC1.0 GPUs are hopefully on the way out with new designs using MC2.0 > this shouldn't be much of a problem going forward. Maybe we can even > simply solve this issue by just dropping the check if PHYS_OFFSET isn't > defined. I guess something like that should work then: -------------------------------->8-------------------------------- -------------------------------->8-------------------------------- > At least I hope VeriSilicon didn't sell you a MC1.0 part at > this time... Given "chipMinorFeatures0_MC20" bit is set for us I would think that we indeed have MC2.0 in our chip. -Alexey diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index fc9a6a83dfc7..5ad191a605e2 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -678,6 +678,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)                 goto fail;         }   +#ifdef PHYS_OFFSET         /*          * Set the GPU linear window to be at the end of the DMA window, where          * the CMA area is likely to reside. This ensures that we are able to @@ -699,6 +700,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)                 gpu->memory_base = PHYS_OFFSET;                 gpu->identity.features &= ~chipFeatures_FAST_CLEAR;         } +#endif           ret = etnaviv_hw_reset(gpu);         if (ret) {