Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4764907yba; Sun, 12 May 2019 22:08:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqwUoOLQIgwDh+OvVBcM+Lv/2DPdeVTcficBOBztA9JrT4TnYzXhMl7rfOCQr+6BJksGJTHs X-Received: by 2002:a62:f245:: with SMTP id y5mr30829925pfl.12.1557724117960; Sun, 12 May 2019 22:08:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557724117; cv=none; d=google.com; s=arc-20160816; b=jJM4otZfCq25MB9687b/BUqOfUEVYI9jNlHKXWjw7cy2mnNkE88hqmHcWd/zlbmEw1 rmx5NaN6FFRPY72lhetOvSGs0XxjZtuYw5a74GlHNAui/CA97/3YHf/iXVDSWRO1NNhs eAD7WU2yXmc377kJAiPY/PkEwVwPivWKRVxaI7ZZGllpAxzmXZ8s9E2I+jfSkZLSWxJv JfX5wHSl2Yp0nVltmY+RjcNXlb9P9mJn9IEZG6XDNbj67ainlraaqzL9sR1L75bkh05n j9sbzjFqT1VFmUxlcFbuJacD5TG4eFzd3hjMSpP5NfXCPjnx/pkN42KXD6lY24MjgPtj ChtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=27ZB4QUSeclbHQB4giHJgMeOF6M2DNc7/NmyRhlP14w=; b=Gu/TZVo24kZlkQksdvq4TkSNp8dxs//P7Kff5gyJ7aAEaZFrN4vuxRWQpOwR5c+BBS CrjYNr8OZS5Epewmt6XC3p58tK8ZYNgX4nhz7N6tyek4nZVBm6h/4Wd/On37l/swLwcS Cx5hWXhxRAq73Mauh2kzcvR8ss1uZtm+7CBeH8HYDZxpF24HXbzXnpozKwQqxGvLlTh9 eMYSqXAhqoUcQ9sgfnxJZn0OZwiw1jKpcwuwjY5jGXbei+UWYDPjNfrHXccZcatLwwHH TYL4hmmiIdZZVhcJHx0jfpLJYsMm/Bqf6RsyKoGaW5G55hzlLSRApRx0HBV9LE+HPVWr L+VA== 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 b15si13102401plz.359.2019.05.12.22.07.55; Sun, 12 May 2019 22:08:37 -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 S1727210AbfEMESf (ORCPT + 99 others); Mon, 13 May 2019 00:18:35 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:7629 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726626AbfEMESf (ORCPT ); Mon, 13 May 2019 00:18:35 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 8E3DD6189E32D9974D90; Mon, 13 May 2019 12:18:33 +0800 (CST) Received: from HGHY2Y004646261.china.huawei.com (10.184.12.158) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.439.0; Mon, 13 May 2019 12:18:23 +0800 From: Zenghui Yu To: , , , CC: , , , , , Zenghui Yu Subject: [RFC PATCH] irqchip/gic-v3: Correct the usage of GICD_CTLR's RWP field Date: Mon, 13 May 2019 04:15:54 +0000 Message-ID: <1557720954-6592-1-git-send-email-yuzenghui@huawei.com> X-Mailer: git-send-email 2.6.4.windows.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.184.12.158] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As per ARM IHI 0069D, GICD_CTLR's RWP field tracks updates to: GICD_CTLR's Group Enable bits, for transitions from 1 to 0 only GICD_CTLR's ARE bits, E1NWF bit and DS bit (if we have) GICD_ICENABLER We seemed use this field in an inappropriate way, somewhere in the GIC-v3 driver. For some examples: In gic_set_affinity(), if the interrupt was not enabled, we only need to write GICD_IROUTER with the appropriate mpidr value. Updates to GICD_IROUTER will not be tracked by RWP field, and we can remove the unnecessary RWP waiting. In gic_dist_init(), we "Enable distributor with ARE, Group1" by writing to GICD_CTLR, and we should use gic_dist_wait_for_rwp() here. These two are obvious cases, and there are some other cases where we don't need to do RWP waiting, such as in gic_configure_irq() and gic_poke_irq(). But too many modifications makes me not confident. It's hard for me to say whether this patch is doing the right thing and how does the RWP waiting affect the system, thus RFC. Signed-off-by: Zenghui Yu --- drivers/irqchip/irq-gic-v3.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c index 15e55d3..8d63950 100644 --- a/drivers/irqchip/irq-gic-v3.c +++ b/drivers/irqchip/irq-gic-v3.c @@ -600,6 +600,7 @@ static void __init gic_dist_init(void) /* Enable distributor with ARE, Group1 */ writel_relaxed(GICD_CTLR_ARE_NS | GICD_CTLR_ENABLE_G1A | GICD_CTLR_ENABLE_G1, base + GICD_CTLR); + gic_dist_wait_for_rwp(); /* * Set all global interrupts to the boot CPU only. ARE must be @@ -986,14 +987,9 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val, gic_write_irouter(val, reg); - /* - * If the interrupt was enabled, enabled it again. Otherwise, - * just wait for the distributor to have digested our changes. - */ + /* If the interrupt was enabled, enabled it again. */ if (enabled) gic_unmask_irq(d); - else - gic_dist_wait_for_rwp(); irq_data_update_effective_affinity(d, cpumask_of(cpu)); -- 1.8.3.1