Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3338236imm; Fri, 25 May 2018 04:07:43 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqt3ftT/mc0gdWGg5Iqhc6QNXz7As0da4XJ3Jgq9f+A2LL9vP50y0zDFJJ23mkn/k/jOfc9 X-Received: by 2002:a63:6584:: with SMTP id z126-v6mr1649724pgb.168.1527246463869; Fri, 25 May 2018 04:07:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527246463; cv=none; d=google.com; s=arc-20160816; b=FGpmMSIEuM4rYGmBKgqFYzhzbtl6ZczdQD7rxqv6aa4pF1zewVNtsOfFjxigVoiASs 3M1hcnPe3UepAz1qqdfohWFanSYPC4ymR3Erm8Z+ZIQOveb7nQX4I5EwFjGFJbrt/VlF kO24I2tJ0hURN4DOGotKEPEKODb140EeuVqYjMKfC2hM6/b05NF1S+sj1uKwzXG4hr3g F2mtyYzXBTyqUx2oC9H0DFSAQIaTSOCqVskE3lTQBRQ9P7Jhs6N8wIfWs1C9aossNGcO C/F9bZr406AdE9FFfVj+vgkaeeYyq2bkzzhd1zc6guK7HJnK72k41uZQ5wQ5nQFeiGI3 Vi/Q== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :arc-authentication-results; bh=f8Pfg8c9Aunf5AOnUV/+glKAmQ4r3DhMJmAfJBLv0e0=; b=UTfPMKxQCfD0ewFgyVIvfO9S3VgboLuKAxF5XMc4ljivzdm3uPLhofMTyXZFFc+yFG ImlLg60klXBqORlJmRQSyAd0o87ZZLv/5RmmF3RBIb1Fl/WGUJzLCa5919CsLahd27z2 roxk5gWMxFoGpAZVdSdLTBdAv0AmfOaRMMUSm7PFCIHbSlL/iae8YYXkdodoJRF9CH60 4mrt0zH4pMjas2yziZiWrAFhfAudWX9y+YwMsvkE8oOCC9EnPDp19gbXRvY+F1ICLHDA jM8c1Op9pUYqUMcKQyoBH+lUOnoMHW2bkoZ9ohq4/r/USPckjBSe6BDaZnK9W/A4XZxw LcsQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o12-v6si23761992pfd.199.2018.05.25.04.07.27; Fri, 25 May 2018 04:07:43 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966260AbeEYLHN (ORCPT + 99 others); Fri, 25 May 2018 07:07:13 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:59842 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965872AbeEYLHK (ORCPT ); Fri, 25 May 2018 07:07:10 -0400 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 1350B80D; Fri, 25 May 2018 04:07:10 -0700 (PDT) Received: from [10.1.206.75] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C2B0A3F24A; Fri, 25 May 2018 04:07:04 -0700 (PDT) Subject: Re: [PATCH] drm/rockchip: vop: fix irq disabled after vop driver probed To: =?UTF-8?Q?Heiko_St=c3=bcbner?= , Ezequiel Garcia Cc: xxm@rock-chips.com, Joerg Roedel , Jeffy Chen , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Tomeu Vizoso , jcliang@chromium.org, linux-rockchip@lists.infradead.org, iommu@lists.linux-foundation.org, =?UTF-8?Q?Enric_Balletb=c3=b2?= , tfiga@chromium.org, Robin Murphy , linux-arm-kernel@lists.infradead.org References: <25470133.K8n9sLBzRS@diego> From: Marc Zyngier Organization: ARM Ltd Message-ID: <8495bffd-2a52-ca85-1bc9-afc3ea0af8e4@arm.com> Date: Fri, 25 May 2018 12:07:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <25470133.K8n9sLBzRS@diego> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Thanks Robin for pointing me to that patch.] Hi Heiko, On 24/05/18 23:06, Heiko Stübner wrote: > From: Sandy Huang > > The vop irq is shared between vop and iommu and irq probing in the > iommu driver moved to the probe function recently. This can in some > cases lead to a stall if the irq is triggered while the vop driver > still has it disabled. > > But there is no real need to disable the irq, as the vop can simply > also track its enabled state and ignore irqs in that case. > > So remove the enable/disable handling and add appropriate condition > to the irq handler. > > Signed-off-by: Sandy Huang > [added an actual commit message] > Signed-off-by: Heiko Stuebner > --- > Hi Ezequiel, > > this patch came from a discussion I had with Rockchip people over the > iommu changes and resulting issues back in april, but somehow was > forgotten and not posted to the lists. Correcting that now. > > So removing the enable/disable voodoo on the shared interrupt is > the preferred way. > > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 ++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > index 510cdf0..61493d4 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > @@ -549,8 +549,6 @@ static int vop_enable(struct drm_crtc *crtc) > > spin_unlock(&vop->reg_lock); > > - enable_irq(vop->irq); > - > drm_crtc_vblank_on(crtc); > > return 0; > @@ -596,8 +594,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc, > > vop_dsp_hold_valid_irq_disable(vop); > > - disable_irq(vop->irq); > - > vop->is_enabled = false; > > /* > @@ -1168,6 +1164,13 @@ static irqreturn_t vop_isr(int irq, void *data) > int ret = IRQ_NONE; > > /* > + * since the irq is shared with iommu, iommu irq is enabled before vop > + * enable, so before vop enable we do nothing. > + */ > + if (!vop->is_enabled) > + return IRQ_NONE; > + What guarantee do we have that the IOMMU will actually service that interrupt? Can't we get into a situation where the interrupt gets ignored by both drivers and subsequently disabled by the core irq code as being spurious? From what I understood of the way things are plugged together on the rockchip platforms, each individual VOP is behind a single IOMMU, hence there there is hardly any point in handling IOMMU interrupts if the VOP is off. But I'm missing the actual reason behind this patch. Could you enlighten me? Thanks, M. -- Jazz is not dead. It just smells funny...