Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp513022ybb; Wed, 1 Apr 2020 04:39:19 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvfn+sxVvofvCUY9rb21z2NzXUvH4vOd3G6mBLZNtxlSQ+wo+ObAYKyYSYY3X3daGXfH72+ X-Received: by 2002:a05:6830:19ec:: with SMTP id t12mr6334254ott.24.1585741158982; Wed, 01 Apr 2020 04:39:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585741158; cv=none; d=google.com; s=arc-20160816; b=jQolT+2WgsxrGcTVOs7tqLS57SwghjIEg9hiZiGQMzay2xBRZD7FnzN+bjvXOnDMup J+kO1mQNSg8vd+DmrJzqF2R8pgqX4UOQ9QTWrIeFC/oem9e/PnSp7uqTDI6JWPZnYk6A QGW6O9Z29nWPv6AvZGXu0PkpHTjzgpGkJZuRYeZC4PluiHdtnFAJjlINJ18PwG07ZEkk GlvsFDYzAHzALL0/9gDUwEqLsqJpLMYLHf6vMYNp0EVLlWrXP2PgSYSAhrgBgCnUfW+g Rv/7QnhaI8PUX+rHOdrm/E1YbYqcmbHCfMn/Z60AStKiRB3OdRQOiY3f7FlCeurhr0nG Ya4A== 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:from:references:cc:to:subject; bh=h0xrRliAbBx0WVlWKVV0V1PYaiYyp5AR379x7i5T8P8=; b=Df33gPhNmbXMOQM9SfpQ0h3O6C5lurWMXKmwaA9vFVkS/YcQ9BGHLuLDq+rouZRjxB Hv4huHxZRSnptiCKB4A8rpLwgBTv9Edu/E8uW1rlvIkyjcwjY9354yP/zjoUoEZOmSxv tHXcM/gi+hUseSf4+rc9V7HfkHHNsmGzVsBj6kkP+74clOxIuVB1N9Q4NyKc3sLX6OHr WgltzYOosU/nPmkhEF3xpOfcIa5j+JyvptIfGX3JfmfAWOLnQWCaeoAlgKZTkwWcOU+Q svSAOt0E4UkSXfEhpnNsWj8bmqcaeviTjRc6/E0tFOuPMFBoj0vLh7+qUhWPbd/59H9O tv2w== 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 e4si834401oib.135.2020.04.01.04.39.02; Wed, 01 Apr 2020 04:39:18 -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 S1732298AbgDALM2 (ORCPT + 99 others); Wed, 1 Apr 2020 07:12:28 -0400 Received: from foss.arm.com ([217.140.110.172]:49152 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731343AbgDALM2 (ORCPT ); Wed, 1 Apr 2020 07:12:28 -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 CDAA930E; Wed, 1 Apr 2020 04:12:27 -0700 (PDT) Received: from [10.57.60.204] (unknown [10.57.60.204]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E6EFA3F68F; Wed, 1 Apr 2020 04:12:25 -0700 (PDT) Subject: Re: [PATCH] driver/perf: Add PMU driver for the ARM DMC-620 memory controller. To: Will Deacon , Mark Rutland Cc: Tuan Phan , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Tuan Phan References: <1584491381-31492-1-git-send-email-tuanphan@os.amperecomputing.com> <20200319151646.GC4876@lakrids.cambridge.arm.com> <23AD5E45-15E3-4487-9B0D-0D9554DD9DE8@amperemail.onmicrosoft.com> <20200320105315.GA35932@C02TD0UTHF1T.local> <20200401095226.GA17163@C02TD0UTHF1T.local> <20200401102724.GA17575@willie-the-truck> From: Robin Murphy Message-ID: <4d843ec7-ed74-4431-d8c7-d5aa6bd83c18@arm.com> Date: Wed, 1 Apr 2020 12:12:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200401102724.GA17575@willie-the-truck> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-04-01 11:27 am, Will Deacon wrote: > On Wed, Apr 01, 2020 at 10:52:26AM +0100, Mark Rutland wrote: >> On Tue, Mar 31, 2020 at 03:14:59PM -0700, Tuan Phan wrote: >>>> On Mar 20, 2020, at 4:25 AM, Mark Rutland wrote: >>>> On Thu, Mar 19, 2020 at 12:03:43PM -0700, Tuan Phan wrote: >>>>>> On Mar 19, 2020, at 8:16 AM, Mark Rutland wrote: >>>>>> On Tue, Mar 17, 2020 at 05:29:38PM -0700, Tuan Phan wrote: >>>>>>> +static int arm_dmc620_pmu_dev_init(struct arm_dmc620_pmu *dmc620_pmu) >>>>>>> +{ >>>>>>> + struct platform_device *pdev = dmc620_pmu->pdev; >>>>>>> + int ret; >>>>>>> + >>>>>>> + ret = devm_request_irq(&pdev->dev, dmc620_pmu->irq, >>>>>>> + arm_dmc620_pmu_handle_irq, >>>>>>> + IRQF_SHARED, >>>>>>> + dev_name(&pdev->dev), dmc620_pmu); >>>>>> >>>>>> This should have IRQF_NOBALANCING | IRQF_NO_THREAD. I don't think we >>>>>> should have IRQF_SHARED. >>>>> => I agree on having IRQF_NOBALANCING and IRQF_NO_THREAD. But >>>>> IRQF_SHARED is needed. In our platform all DMC620s share same IRQs and >>>>> any cpus can access the pmu registers. >>>> >>>> Linux needs to ensure that the same instance is concistently accessed >>>> from the same CPU, and needs to migrate the IRQ to handle that. Given we >>>> do that on a per-instance basis, we cannot share the IRQ with another >>>> instance. >>>> >>>> Please feed back to you HW designers that muxing IRQs like this causes >>>> significant problems for software. >>> >>> I looked at the SMMUv3 PMU driver and it also uses IRQF_SHARED. SMMUv3 >>> PMU and DMC620 PMU are very much similar in which counters can be >>> accessed by any cores using memory map. Any special reasons >>> IRQF_SHARED works with SMMUv3 PMU driver? >> >> No; I believe that is a bug in the SMMUv3 PMU driver. If the IRQ were >> shared, and another driver that held the IRQ changed the affinity, >> things would go very wrong. > > I *think* the idea is that the SMMUv3 PMU driver manages multiple PMCG > devices, which may all share an irq line, rather than the irq line being > shared by some other driver that might change the affinity. So I suspect > dropping IRQF_SHARED will break things. Each PMCG is conceptually a distinct PMU with its own interrupt - for instance, MMU-600 has one PMCG for its TCU and one for each TBU, each with a distinct interrupt output signal. Of course, integrators can and will mash them all together into a single SPI (particularly since they're all part of "the SMMU"), but that boils down to the same case as here. This is going to continue to happen, so we could really do with figuring out a way to let MMIO system PMU drivers properly cope with shared interrupts in general :/ Robin.