From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF54FC4360F for ; Tue, 2 Apr 2019 11:23:41 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8AEE520883 for ; Tue, 2 Apr 2019 11:23:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jj8PKDlt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8AEE520883 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=C4BWwlf+YyGecoxffyl/Us2jIs+/sOZ5zyx/IMYpFQ8=; b=jj8PKDlty/TN0I7jNiT7cpySO NfxIn+D0gRK7w5w/Ayv0f7N+vl1j0+nzsFGvExH9dHUXlKeSETyq78rxQ/UI+YxJu7Rnp75WR3cQE 12JzMcZXLmr1e0JNAJK37GEqtynnbG1ds0tc33yqnaOflUpGqMRgcGBxBA3YafqoaVKi2UcJJ4jdD 9SPBpzd2JN5Quw9s4Ui/N+mPhYp0JQ2Q2G3RVI1v3Nje3IqMbA0S9YQ0uSHuNPYqLQ3LUdFulBVU0 3p/xR4K2IqKARmDbSjbOKhOuS+cH6KUBlywv/i7hWi0hCbhYSQ1/LXkVSdMGt1kzbogy1B+S05A7n cK2BuXdag==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBHVv-0004kC-Qp; Tue, 02 Apr 2019 11:23:35 +0000 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70] helo=foss.arm.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBHVs-0004jU-Ks for linux-arm-kernel@lists.infradead.org; Tue, 02 Apr 2019 11:23:34 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 90186168F; Tue, 2 Apr 2019 04:23:30 -0700 (PDT) Received: from [10.1.196.75] (e110467-lin.cambridge.arm.com [10.1.196.75]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BBBF93F59C; Tue, 2 Apr 2019 04:23:27 -0700 (PDT) Subject: Re: [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver To: Alyssa Rosenzweig References: <20190401074730.12241-1-robh@kernel.org> <20190401074730.12241-4-robh@kernel.org> <6ce32759-ea83-ee79-33d3-237737f7b866@arm.com> <20190402003326.GB12934@rosenzweig.io> From: Robin Murphy Message-ID: Date: Tue, 2 Apr 2019 12:23:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190402003326.GB12934@rosenzweig.io> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190402_042332_692112_DAD3E366 X-CRM114-Status: GOOD ( 18.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rob Herring , Lyude Paul , Tomeu Vizoso , Neil Armstrong , Maxime Ripard , Will Deacon , David Airlie , Maarten Lankhorst , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Eric Anholt , iommu@lists.linux-foundation.org, Daniel Vetter , "Marty E . Plummer" , Sean Paul , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 02/04/2019 01:33, Alyssa Rosenzweig wrote: >> the userspace definitely doesn't support T624 > > This is true, yes. Shouldn't be too hard to backport; if there's still > interest in Midgard 1st/2nd gen, I suppose I can grab hardware and sort > it out... I'm quite likely the only person trying this on an Arm Juno board, and even then it's really only for giggles because I can :) I guess there might be a fair few Odroid-XU3/XU4 (T628) users interested, though. >> You probably want a dma_set_mask_and_coherent() call for your 'real' output >> address size somewhere - the default 32-bit mask works out OK for RK3399, >> but on systems with RAM above 4GB io-pgtable will get very unhappy about DMA >> bounce-buffering. > > Out of curiosity, are there Mali systems with >4GB RAM? That sounds > awesome :) Now that the "early-access Armv8 silicon" angle has well and truly expired, Juno is essentially a prototyping platform where the SoC just serves to (slowly) drive interesting things in FPGA cards, so although it may have 8GB of RAM, it's not all that exciting. There is one somewhat more realistic board I'm aware of, namely HiKey 970 with a G72 and 6GB. >> Any chance of resurrecting the generic "arm,mali-midgard" compatible? :P > > ...Would that require editing everybody's DT file? If they already have one of the strings from the current upstream binding, no - I only mean to suggest adding it as an additional last-level fallback. That would aid compatibility with downstream DTs, for example RK3288 which currently has zero overlap: upstream: "rockchip,rk3288-mali", "arm,mali-t760"; downstream: "arm,malit764", "arm,malit76x", "arm,malit7xx", "arm,mali-midgard"; Similarly, it might be reasonable for panfrost_{gpu,mmu,job}_init() to retry platform_get_irq_byname() with uppercase interrupt names if the expected ones aren't found - obviously the upstream binding comes first and foremost, but I don't see any harm in quietly supporting bits of the downstream binding if it makes users' lives easier when switching between mainline and vendor kernels. Cheers, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel