Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp512976ybi; Fri, 31 May 2019 05:07:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqxSZCyX8PAxoH/b7THHuk1BKXYaC0wTbpGWYISaKXW36+NRmNaWAWPU3VDNtQZ9avqZhUZG X-Received: by 2002:a17:90a:b890:: with SMTP id o16mr8866141pjr.60.1559304421532; Fri, 31 May 2019 05:07:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559304421; cv=none; d=google.com; s=arc-20160816; b=fw4wQc5EmRqx7jr64yJCWvaPe1EoOtOGC43KjjbaE/gy3GFMq94uCNO4b8pT0/hM8a bv71v7sjCn0th1NCtCW7hft6gzer3x9tU37u1dxorvbdfO2X6UcLEl2DhN9vt68UYNxQ xzhozMt12earvU7Ulkh/a0gtY5B7SmjgwYZtidM1sszjHtJv4DbETI7FnQ9nJcgxazpR zkhp5DOQk/X/faK/6Q8iXvge7UWqRcOt4eg7Q5H4uXocciDt6s2D5NY5Cv5LvLscLiZn XgxmEWzCfgZTRYitxrSVbFP+XCI0wftpxbu04/1wRFYBs7LsjqSfzIucbJksQEFX+7Uf vAAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=+natQ9Y8n1ltusUoNKJ2QqepbXrWXhif6by64DfgqSM=; b=VGNDuJr5eA3E8bDRh+4ffm8TG3xsb98mGyNKp84b+gS1jT2bWzkjbbV0Py0H0PViob TrYnRlMgEPVlPy4+uhFr2HyAg67v5t8zxe+9rtPB22L27IQqXsaoYUg3Kdf8aCUb9GzX JtC1ZV+sOmdW4JYpIvZkfZplYEmoq29NFy2n/R19hxTnWhy6u9jvTwT/LLRPbyPWU/FI kSa1SG37Iwg8bd9mh6oYbFhWFEu3dvtjHK8RDqbyllRvjGEIahiwsxJJqNmtP3BwvTQ3 mEhaxT9t8eBd9uIW8+8oWlLeEd8CEbhvxyBFaSlzHmCvI0Evb1K7UVBagyQ+y3lZJUKt VaBQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b20si5299767pjo.107.2019.05.31.05.06.37; Fri, 31 May 2019 05:07:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727188AbfEaMFD convert rfc822-to-8bit (ORCPT + 99 others); Fri, 31 May 2019 08:05:03 -0400 Received: from mail-it1-f194.google.com ([209.85.166.194]:50471 "EHLO mail-it1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726330AbfEaMFC (ORCPT ); Fri, 31 May 2019 08:05:02 -0400 Received: by mail-it1-f194.google.com with SMTP id a186so15286664itg.0; Fri, 31 May 2019 05:05:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tqrmQ2U13+xCmSb38oWvwz7Ya/O77rdp+A5n3MJMo9s=; b=krGIpURES88Ty01kUgOACUwryJ9JeQTULTyI7CeFFdvF1WXZ2llOKVDgXatHuc0l2X s+RNsWuSjANmENV+lPSKHCvrdulLS8IoA+PLuIY8+LLo4Xg2wZ0PHADENAwROBIzjJ9J 6ZJw+x0yD0gRzm1hkSe4Q5RlXqGR/+EHbosdWguUSujE5RWLk5oS9BPrJej2d88+rY40 oFtuOBSPf++lWgj8fPzEhOSAEbc8IO7nj/et3TvgrhoFP28ISLRRmH5cpzncI0fHPUki nkDCWBtJQhorsQqFREKD1CSaWO5r+Sy8beT5NmH+sORKopFRY9Qd8TXI5hjS3OO2kP7i 0ZVQ== X-Gm-Message-State: APjAAAUuK6gBqIWn/7WdBDNlWVMDuteN3h0B5aaObTIHi9tHvS/IywIC 816lKK55bor3zWVEFojx1U5OASUufourBgqAKr4= X-Received: by 2002:a24:5a45:: with SMTP id v66mr6900489ita.140.1559304302034; Fri, 31 May 2019 05:05:02 -0700 (PDT) MIME-Version: 1.0 References: <20190521161102.29620-1-peron.clem@gmail.com> <4ff02295-6c34-791b-49f4-6558a92ad7a3@arm.com> In-Reply-To: <4ff02295-6c34-791b-49f4-6558a92ad7a3@arm.com> From: Tomeu Vizoso Date: Fri, 31 May 2019 14:04:50 +0200 Message-ID: Subject: Re: [PATCH v6 0/6] Allwinner H6 Mali GPU support To: Robin Murphy Cc: =?UTF-8?B?Q2zDqW1lbnQgUMOpcm9u?= , Mark Rutland , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Neil Armstrong , David Airlie , Will Deacon , open list , dri-devel , Steven Price , Maxime Ripard , Chen-Yu Tsai , Rob Herring , Linux IOMMU , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 29 May 2019 at 19:38, Robin Murphy wrote: > > On 29/05/2019 16:09, Tomeu Vizoso wrote: > > On Tue, 21 May 2019 at 18:11, Clément Péron wrote: > >> > > [snip] > >> [ 345.204813] panfrost 1800000.gpu: mmu irq status=1 > >> [ 345.209617] panfrost 1800000.gpu: Unhandled Page fault in AS0 at VA > >> 0x0000000002400400 > > > > From what I can see here, 0x0000000002400400 points to the first byte > > of the first submitted job descriptor. > > > > So mapping buffers for the GPU doesn't seem to be working at all on > > 64-bit T-760. > > > > Steven, Robin, do you have any idea of why this could be? > > I tried rolling back to the old panfrost/nondrm shim, and it works fine > with kbase, and I also found that T-820 falls over in the exact same > manner, so the fact that it seemed to be common to the smaller 33-bit > designs rather than anything to do with the other > job_descriptor_size/v4/v5 complication turned out to be telling. Is this complication something you can explain? I don't know what v4 and v5 are meant here. > [ as an aside, are 64-bit jobs actually known not to work on v4 GPUs, or > is it just that nobody's yet observed a 64-bit blob driving one? ] I'm looking right now at getting Panfrost working on T720 with 64-bit descriptors, with the ultimate goal of making Panfrost 64-bit-descriptor only so we can have a single build of Mesa in distros. > Long story short, it appears that 'Mali LPAE' is also lacking the start > level notion of VMSA, and expects a full 4-level table even for <40 bits > when level 0 effectively redundant. Thus walking the 3-level table that > io-pgtable comes back with ends up going wildly wrong. The hack below > seems to do the job for me; if Clément can confirm (on T-720 you'll > still need the userspace hack to force 32-bit jobs as well) then I think > I'll cook up a proper refactoring of the allocator to put things right. Mmaps seem to work with this patch, thanks. The main complication I'm facing right now seems to be that the SFBD descriptor on T720 seems to be different from the one we already had (tested on T6xx?). Cheers, Tomeu > Robin. > > > ----->8----- > diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c > index 546968d8a349..f29da6e8dc08 100644 > --- a/drivers/iommu/io-pgtable-arm.c > +++ b/drivers/iommu/io-pgtable-arm.c > @@ -1023,12 +1023,14 @@ arm_mali_lpae_alloc_pgtable(struct > io_pgtable_cfg *cfg, void *cookie) > iop = arm_64_lpae_alloc_pgtable_s1(cfg, cookie); > if (iop) { > u64 mair, ttbr; > + struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(&iop->ops); > > + data->levels = 4; > /* Copy values as union fields overlap */ > mair = cfg->arm_lpae_s1_cfg.mair[0]; > ttbr = cfg->arm_lpae_s1_cfg.ttbr[0]; > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel