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=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 73FC1C433ED for ; Tue, 20 Apr 2021 11:01:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 30064613B0 for ; Tue, 20 Apr 2021 11:01:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231388AbhDTLBq convert rfc822-to-8bit (ORCPT ); Tue, 20 Apr 2021 07:01:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:40014 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230290AbhDTLBp (ORCPT ); Tue, 20 Apr 2021 07:01:45 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5A44B61026; Tue, 20 Apr 2021 11:01:14 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lYo80-008TZz-2b; Tue, 20 Apr 2021 12:01:12 +0100 Date: Tue, 20 Apr 2021 12:01:10 +0100 Message-ID: <87bla9qky1.wl-maz@kernel.org> From: Marc Zyngier To: Pali =?UTF-8?B?Um9ow6Fy?= Cc: Jianjun Wang , Bjorn Helgaas , Rob Herring , Lorenzo Pieralisi , Ryder Lee , Philipp Zabel , Matthias Brugger , linux-pci@vger.kernel.org, linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, youlin.pei@mediatek.com, chuanjia.liu@mediatek.com, qizhong.cheng@mediatek.com, sin_jieyang@mediatek.com, drinkcat@chromium.org, Rex-BC.Chen@mediatek.com, anson.chuang@mediatek.com, Krzysztof Wilczyski Subject: Re: [PATCH v10 5/7] PCI: mediatek-gen3: Add MSI support In-Reply-To: <20210420094402.hwdkbspl5wu4rtex@pali> References: <20210420061723.989-1-jianjun.wang@mediatek.com> <20210420061723.989-6-jianjun.wang@mediatek.com> <20210420094402.hwdkbspl5wu4rtex@pali> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: pali@kernel.org, jianjun.wang@mediatek.com, bhelgaas@google.com, robh+dt@kernel.org, lorenzo.pieralisi@arm.com, ryder.lee@mediatek.com, p.zabel@pengutronix.de, matthias.bgg@gmail.com, linux-pci@vger.kernel.org, linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, youlin.pei@mediatek.com, chuanjia.liu@mediatek.com, qizhong.cheng@mediatek.com, sin_jieyang@mediatek.com, drinkcat@chromium.org, Rex-BC.Chen@mediatek.com, anson.chuang@mediatek.com, kw@linux.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, 20 Apr 2021 10:44:02 +0100, Pali Rohár wrote: > > Hello! > > On Tuesday 20 April 2021 14:17:21 Jianjun Wang wrote: > > +static void mtk_pcie_enable_msi(struct mtk_pcie_port *port) > > +{ > > + int i; > > + u32 val; > > + > > + for (i = 0; i < PCIE_MSI_SET_NUM; i++) { > > + struct mtk_msi_set *msi_set = &port->msi_sets[i]; > > + > > + msi_set->base = port->base + PCIE_MSI_SET_BASE_REG + > > + i * PCIE_MSI_SET_OFFSET; > > + msi_set->msg_addr = port->reg_base + PCIE_MSI_SET_BASE_REG + > > + i * PCIE_MSI_SET_OFFSET; > > + > > + /* Configure the MSI capture address */ > > + writel_relaxed(lower_32_bits(msi_set->msg_addr), msi_set->base); > > + writel_relaxed(upper_32_bits(msi_set->msg_addr), > > + port->base + PCIE_MSI_SET_ADDR_HI_BASE + > > + i * PCIE_MSI_SET_ADDR_HI_OFFSET); > > This looks like as setting MSI doorbell address to MSI doorbell address. > > > +static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) > > +{ > > + struct mtk_msi_set *msi_set = irq_data_get_irq_chip_data(data); > > + struct mtk_pcie_port *port = data->domain->host_data; > > + unsigned long hwirq; > > + > > + hwirq = data->hwirq % PCIE_MSI_IRQS_PER_SET; > > + > > + msg->address_hi = upper_32_bits(msi_set->msg_addr); > > + msg->address_lo = lower_32_bits(msi_set->msg_addr); > > + msg->data = hwirq; > > + dev_dbg(port->dev, "msi#%#lx address_hi %#x address_lo %#x data %d\n", > > + hwirq, msg->address_hi, msg->address_lo, msg->data); > > ... which is later used in compose_msi_msg(). > > Marc in some other patches for other pci controller drivers changed this > address to just main "port" structure. It simplified implementations and > also avoided need to declare additional member "msg_addr". > > Marc, would it be possible to simplify it also for this driver and just > set msg_addr to virt_to_phys(port)? Maybe. It really depends on what range the HW accepts, and the sole requirement is to use an address that the endpoint cannot DMA to. Here, the driver seems to be using something based on the port base address, which is good enough as far as I am concerned (the thing I usually object to is the allocation of memory just for the sake of getting a capture address). If you want to further simplify it, you could simply use port.reg_base as the MSI address for all sets, as I don't think they have to be distinct. But someone with access to the TRM for this should go and check it. I don't believe this should gate the merging od this driver though. M. -- Without deviation from the norm, progress is not possible.