Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp713282pxj; Tue, 18 May 2021 12:25:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx/ivNS5LGjQBbJsJrYqgN6dS8qkEFsjhl57VanO44GRDHamYGgH4f37SGQJiPfAfHfzRqJ X-Received: by 2002:a05:6402:10cc:: with SMTP id p12mr8959986edu.328.1621365955855; Tue, 18 May 2021 12:25:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621365955; cv=none; d=google.com; s=arc-20160816; b=PWzUW5eQLLMTRMC0U4RzXVw5Ci+npeXjuxoUZZniuDfSXFc3PB+k9nBD1kAIb4NYvm Yg7C1C3+2sC/6nCePhBmiBVz8lD2pBOW5Y8Q0WiQxtW4DNbLgtRbimF55H0dnuEEV18I zExQmsjamYm0uXnHy+riG8lLFWQtwLO1n7ztKUt3Rwc0MwSGgQ0wn9RBbbLS0GXvK09J u9eAeupVks26fEYblZQwsgljw+4U9Nv01hwB0/diDSyv/bJqo6LPcAZ3Xd6VTa4+lek/ jE+SzDXCIlS4lc9Oq5aaPG+yfcxlXrLMRWP9KsoPl5oOJCYFmDKaqADCMNHnH/46rFGW KBQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=GuumyFTA/C9ZBnqOQi5WyLMCN03LPQoLx80/jAZCelk=; b=JA3zY2U3obJO/pvXNiJeeuUINFi6tJZ4gRfWa/1dn83AWN5M/MxyVGubmmwgCseJ8J hWm5Xv3fz6lZEWDXfVKCrpcOA8cReafXeJbh0aX6K28vI0Fz79KewhUde/ckJMB/YBRd o6jkPzjLi0+ARpMLW7etglt6v8oHEi2bb8XSySLnvUcJ3bS8Q0Bez4CCR75G3184F3Lt nf7f3q+HXTw0NMiTGkINHtTlZLU9/w2i1xPLMXoQzILC+CTAncqn8z7PoFootEWNUbRY uy/vR3q7UTth0QX/Z+jNSRHrMyWkJY2ZNJG7sYTSQC6ElN3jX51Tqvu2M3WPNuccP+yA v6iQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a20si14779741eje.479.2021.05.18.12.25.20; Tue, 18 May 2021 12:25:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244737AbhEQQg5 (ORCPT + 99 others); Mon, 17 May 2021 12:36:57 -0400 Received: from foss.arm.com ([217.140.110.172]:57760 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244641AbhEQQgr (ORCPT ); Mon, 17 May 2021 12:36:47 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EEA2C106F; Mon, 17 May 2021 09:35:30 -0700 (PDT) Received: from [10.57.66.179] (unknown [10.57.66.179]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D8D063F73D; Mon, 17 May 2021 09:35:28 -0700 (PDT) Subject: Re: [PATCH v5 4/6] drm/sprd: add Unisoc's drm display controller driver To: Joerg Roedel , Kevin Tang Cc: Maxime Ripard , Maarten Lankhorst , Sean Paul , David Airlie , Daniel Vetter , Rob Herring , Mark Rutland , Orson Zhai , Chunyan Zhang , "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , devicetree@vger.kernel.org References: <20210425123607.26537-1-kevin3.tang@gmail.com> <20210425123607.26537-5-kevin3.tang@gmail.com> <20210430092249.n75to2das5m6p4zb@gilmour> From: Robin Murphy Message-ID: Date: Mon, 17 May 2021 17:35:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-05-17 10:27, Joerg Roedel wrote: > On Fri, Apr 30, 2021 at 08:20:10PM +0800, Kevin Tang wrote: >> Cc Robin & Joerg > > This is just some GPU internal MMU being used here, it seems. It doesn't > use the IOMMU core code, so no Ack needed from the IOMMU side. Except the actual MMU being used is drivers/iommu/sprd_iommu.c - this is just the display driver poking directly at the interrupt registers of its associated IOMMU instance. I still think this is wrong, and that it should be treated as a shared interrupt, with the IOMMU driver handling its own registers and reporting to the client through the standard report_iommu_fault() API, especially since there are apparently more blocks using these IOMMU instances than just the display. Robin.