All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: Jianjun Wang <jianjun.wang@mediatek.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Rob Herring <robh+dt@kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Ryder Lee <ryder.lee@mediatek.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Matthias Brugger <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,
	Krzysztof Wilczyski <kw@linux.com>
Subject: Re: [PATCH v10 5/7] PCI: mediatek-gen3: Add MSI support
Date: Tue, 20 Apr 2021 13:08:32 +0200	[thread overview]
Message-ID: <20210420110832.iyjck2m2s5jlit26@pali> (raw)
In-Reply-To: <87bla9qky1.wl-maz@kernel.org>

On Tuesday 20 April 2021 12:01:10 Marc Zyngier wrote:
> On Tue, 20 Apr 2021 10:44:02 +0100,
> Pali Rohár <pali@kernel.org> 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.

Of course! I'm just asking details to understand best practises and how
it works. So thanks for information!

> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.

WARNING: multiple messages have this Message-ID (diff)
From: "Pali Rohár" <pali@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: Jianjun Wang <jianjun.wang@mediatek.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Rob Herring <robh+dt@kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Ryder Lee <ryder.lee@mediatek.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Matthias Brugger <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,
	Krzysztof Wilczyski <kw@linux.com>
Subject: Re: [PATCH v10 5/7] PCI: mediatek-gen3: Add MSI support
Date: Tue, 20 Apr 2021 13:08:32 +0200	[thread overview]
Message-ID: <20210420110832.iyjck2m2s5jlit26@pali> (raw)
In-Reply-To: <87bla9qky1.wl-maz@kernel.org>

On Tuesday 20 April 2021 12:01:10 Marc Zyngier wrote:
> On Tue, 20 Apr 2021 10:44:02 +0100,
> Pali Rohár <pali@kernel.org> 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.

Of course! I'm just asking details to understand best practises and how
it works. So thanks for information!

> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: "Pali Rohár" <pali@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: Jianjun Wang <jianjun.wang@mediatek.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Rob Herring <robh+dt@kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Ryder Lee <ryder.lee@mediatek.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Matthias Brugger <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,
	Krzysztof Wilczyski <kw@linux.com>
Subject: Re: [PATCH v10 5/7] PCI: mediatek-gen3: Add MSI support
Date: Tue, 20 Apr 2021 13:08:32 +0200	[thread overview]
Message-ID: <20210420110832.iyjck2m2s5jlit26@pali> (raw)
In-Reply-To: <87bla9qky1.wl-maz@kernel.org>

On Tuesday 20 April 2021 12:01:10 Marc Zyngier wrote:
> On Tue, 20 Apr 2021 10:44:02 +0100,
> Pali Rohár <pali@kernel.org> 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.

Of course! I'm just asking details to understand best practises and how
it works. So thanks for information!

> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-04-20 11:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20  6:17 [PATCH v10 0/7] PCI: mediatek: Add new generation controller support Jianjun Wang
2021-04-20  6:17 ` Jianjun Wang
2021-04-20  6:17 ` Jianjun Wang
2021-04-20  6:17 ` [PATCH v10 1/7] dt-bindings: PCI: mediatek-gen3: Add YAML schema Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  6:17 ` [PATCH v10 2/7] PCI: Export pci_pio_to_address() for module use Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  6:17 ` [PATCH v10 3/7] PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192 Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  6:17 ` [PATCH v10 4/7] PCI: mediatek-gen3: Add INTx support Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  6:17 ` [PATCH v10 5/7] PCI: mediatek-gen3: Add MSI support Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  9:44   ` Pali Rohár
2021-04-20  9:44     ` Pali Rohár
2021-04-20  9:44     ` Pali Rohár
2021-04-20 11:01     ` Marc Zyngier
2021-04-20 11:01       ` Marc Zyngier
2021-04-20 11:01       ` Marc Zyngier
2021-04-20 11:08       ` Pali Rohár [this message]
2021-04-20 11:08         ` Pali Rohár
2021-04-20 11:08         ` Pali Rohár
2021-04-20  6:17 ` [PATCH v10 6/7] PCI: mediatek-gen3: Add system PM support Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  6:17 ` [PATCH v10 7/7] MAINTAINERS: Add Jianjun Wang as MediaTek PCI co-maintainer Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  6:17   ` Jianjun Wang
2021-04-20  9:12 ` [PATCH v10 0/7] PCI: mediatek: Add new generation controller support Lorenzo Pieralisi
2021-04-20  9:12   ` Lorenzo Pieralisi
2021-04-20  9:12   ` Lorenzo Pieralisi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210420110832.iyjck2m2s5jlit26@pali \
    --to=pali@kernel.org \
    --cc=Rex-BC.Chen@mediatek.com \
    --cc=anson.chuang@mediatek.com \
    --cc=bhelgaas@google.com \
    --cc=chuanjia.liu@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=jianjun.wang@mediatek.com \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=maz@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=qizhong.cheng@mediatek.com \
    --cc=robh+dt@kernel.org \
    --cc=ryder.lee@mediatek.com \
    --cc=sin_jieyang@mediatek.com \
    --cc=youlin.pei@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.