linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Frank Li <Frank.li@nxp.com>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
	"Richard Zhu" <hongxing.zhu@nxp.com>,
	"Lucas Stach" <l.stach@pengutronix.de>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Rob Herring" <robh@kernel.org>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabio Estevam" <festevam@gmail.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev,
	alyssa@rosenzweig.io, bpf@vger.kernel.org, broonie@kernel.org,
	jgg@ziepe.ca, joro@8bytes.org, lgirdwood@gmail.com,
	maz@kernel.org, p.zabel@pengutronix.de, robin.murphy@arm.com,
	will@kernel.org
Subject: Re: [PATCH v8 2/2] PCI: imx6: Add IOMMU and ITS MSI support for i.MX95
Date: Fri, 13 Dec 2024 10:32:28 +0100	[thread overview]
Message-ID: <Z1v/LCHsGOgnasuf@lpieralisi> (raw)
In-Reply-To: <Z1sdbH7N1Ly9eXc0@lizhi-Precision-Tower-5810>

On Thu, Dec 12, 2024 at 12:29:16PM -0500, Frank Li wrote:
> On Thu, Dec 12, 2024 at 05:46:09PM +0100, Lorenzo Pieralisi wrote:
> > On Tue, Dec 10, 2024 at 05:48:59PM -0500, Frank Li wrote:
> > > For the i.MX95, configuration of a LUT is necessary to convert Bus Device
> > > Function (BDF) to stream IDs, which are utilized by both IOMMU and ITS.
> > > This involves checking msi-map and iommu-map device tree properties to
> > > ensure consistent mapping of PCI BDF to the same stream IDs. Subsequently,
> > > LUT-related registers are configured. In the absence of an msi-map, the
> > > built-in MSI controller is utilized as a fallback.
> >
> > This is wrong information. What you want to say is that if an msi-map
> > isn't detected this means that the platform relies on DWC built-in
> > controller for MSIs (that does not need streamIDs handling).
> >
> > That's quite different from what you are writing here.
> 
> How about ?
> 
> "If an msi-map isn't detected, platform relies on DWC built-in controller
> for MSIs that does not need streamdIDs"

Right. Question: what happens if DT shows that there are SMMU and/or
ITS bindings/mappings but the SMMU driver and ITS driver are either not
enabled or have not probed ?

I assume the LUT programming makes no difference (it is useless yes but
should be harmless too) in this case but wanted to check with you.

Thanks,
Lorenzo

> 
> >
> > >
> > > Register a PCI bus callback function to handle enable_device() and
> > > disable_device() operations, setting up the LUT whenever a new PCI device
> > > is enabled.
> > >
> > > Acked-by: Richard Zhu <hongxing.zhu@nxp.com>
> > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> 
> [...]
> 
> > > +	int err_i, err_m;
> > > +	u32 sid;
> > > +
> > > +	dev = imx_pcie->pci->dev;
> > > +
> > > +	target = NULL;
> > > +	err_i = of_map_id(dev->of_node, rid, "iommu-map", "iommu-map-mask", &target, &sid_i);
> > > +	if (target) {
> > > +		of_node_put(target);
> > > +	} else {
> > > +		/*
> > > +		 * "target == NULL && err_i == 0" means use 1:1 map RID to
> >
> > Is it what it means ? Or does it mean that the iommu-map property was found
> > and RID is out of range ?
> 
> yes, if this happen, sid_i will be equal to RID.
> 
> >
> > Could you point me at a sample dts for this host bridge please ?
> 
> https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/arch/arm64/boot/dts/freescale/imx95.dtsi
> 
> /* 0x10~0x17 stream id for pci0 */
>    iommu-map = <0x000 &smmu 0x10 0x1>,
>                <0x100 &smmu 0x11 0x7>;
> 
> /* msi part */
>    msi-map = <0x000 &its 0x10 0x1>,
>              <0x100 &its 0x11 0x7>;
> 
> >
> > > +		 * stream ID. Hardware can't support this because stream ID
> > > +		 * only 5bits
> >
> > It is 5 or 6 bits ? From GENMASK(5, 0) above it should be 6.
> 
> Sorry for typo. it is 6bits.
> 
> >
> > > +		 */
> > > +		err_i = -EINVAL;
> > > +	}
> > > +
> > > +	target = NULL;
> > > +	err_m = of_map_id(dev->of_node, rid, "msi-map", "msi-map-mask", &target, &sid_m);
> > > +
> > > +	/*
> > > +	 *   err_m      target
> > > +	 *	0	NULL		Use 1:1 map RID to stream ID,
> >
> > Again, is that what it really means ?
> >
> > > +	 *				Current hardware can't support it,
> > > +	 *				So return -EINVAL.
> > > +	 *      != 0    NULL		msi-map not exist, use built-in MSI.
> >
> > does not exist.
> >
> > > +	 *	0	!= NULL		Get correct streamID from RID.
> > > +	 *	!= 0	!= NULL		Unexisted case, never happen.
> >
> > "Invalid combination"
> >
> > > +	 */
> > > +	if (!err_m && !target)
> > > +		return -EINVAL;
> > > +	else if (target)
> > > +		of_node_put(target); /* Find stream ID map entry for RID in msi-map */
> > > +
> > > +	/*
> > > +	 * msi-map        iommu-map
> > > +	 *   N                N            DWC MSI Ctrl
> > > +	 *   Y                Y            ITS + SMMU, require the same sid
> > > +	 *   Y                N            ITS
> > > +	 *   N                Y            DWC MSI Ctrl + SMMU
> > > +	 */
> > > +	if (err_i && err_m)
> > > +		return 0;
> > > +
> > > +	if (!err_i && !err_m) {
> > > +		/*
> > > +		 * MSI glue layer auto add 2 bits controller ID ahead of stream
> >
> > What's "MSI glue layer" ?
> 
> It is common term for IC desgin, which connect IP's signal to platform with
> some simple logic. Inside chip, when connect LUT output 6bit streamIDs
> to MSI controller, there are 2bits hardcode controller ID information
> append to 6 bits streamID.
> 
>            Glue Layer
>           <==========>
> ┌─────┐                  ┌──────────┐
> │ LUT │ 6bit stream ID   │          │
> │     ┼─────────────────►│  MSI     │
> └─────┘    2bit ctrl ID  │          │
>             ┌───────────►│          │
>             │            │          │
>  00 PCIe0   │            │          │
>  01 ENETC   │            │          │
>  10 PCIe1   │            │          │
>             │            └──────────┘
> 
> >
> > > +		 * ID, so mask this 2bits to get stream ID.
> > > +		 * But IOMMU glue layer doesn't do that.
> >
> > and "IOMMU glue layer" ?
> 
> See above.
> 
> Frank
> 
> >
> > > +		 */
> > > +		if (sid_i != (sid_m & IMX95_SID_MASK)) {
> > > +			dev_err(dev, "iommu-map and msi-map entries mismatch!\n");
> > > +			return -EINVAL;
> > > +		}
> > > +	}
> > > +
> > > +	sid = sid_i;
> >
> > err_i could be != 0 here, I understand that the end result is
> > fine given how the code is written but it is misleading.
> >
> > 	if (!err_i)
> > 	else if (!err_m)
> 
> Okay
> 
> >
> > > +	if (!err_m)
> > > +		sid = sid_m & IMX95_SID_MASK;
> > > +
> > > +	return imx_pcie_add_lut(imx_pcie, rid, sid);
> > > +}
> > > +
> > > +static void imx_pcie_disable_device(struct pci_host_bridge *bridge, struct pci_dev *pdev)
> > > +{
> > > +	struct imx_pcie *imx_pcie;
> > > +
> > > +	imx_pcie = to_imx_pcie(to_dw_pcie_from_pp(bridge->sysdata));
> > > +	imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev));
> > > +}
> > > +
> > >  static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> > >  {
> > >  	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > > @@ -946,6 +1122,11 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> > >  		}
> > >  	}
> > >
> > > +	if (pp->bridge && imx_check_flag(imx_pcie, IMX_PCIE_FLAG_HAS_LUT)) {
> > > +		pp->bridge->enable_device = imx_pcie_enable_device;
> > > +		pp->bridge->disable_device = imx_pcie_disable_device;
> > > +	}
> > > +
> > >  	imx_pcie_assert_core_reset(imx_pcie);
> > >
> > >  	if (imx_pcie->drvdata->init_phy)
> > > @@ -1330,6 +1511,8 @@ static int imx_pcie_probe(struct platform_device *pdev)
> > >  	imx_pcie->pci = pci;
> > >  	imx_pcie->drvdata = of_device_get_match_data(dev);
> > >
> > > +	mutex_init(&imx_pcie->lock);
> > > +
> > >  	/* Find the PHY if one is defined, only imx7d uses it */
> > >  	np = of_parse_phandle(node, "fsl,imx7d-pcie-phy", 0);
> > >  	if (np) {
> > > @@ -1627,7 +1810,8 @@ static const struct imx_pcie_drvdata drvdata[] = {
> > >  	},
> > >  	[IMX95] = {
> > >  		.variant = IMX95,
> > > -		.flags = IMX_PCIE_FLAG_HAS_SERDES,
> > > +		.flags = IMX_PCIE_FLAG_HAS_SERDES |
> > > +			 IMX_PCIE_FLAG_HAS_LUT,
> > >  		.clk_names = imx8mq_clks,
> > >  		.clks_cnt = ARRAY_SIZE(imx8mq_clks),
> > >  		.ltssm_off = IMX95_PE0_GEN_CTRL_3,
> > >
> > > --
> > > 2.34.1
> > >


  reply	other threads:[~2024-12-13  9:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-10 22:48 [PATCH v8 0/2] PCI: add enabe(disable)_device() hook for bridge Frank Li
2024-12-10 22:48 ` [PATCH v8 1/2] PCI: Add enable_device() and disable_device() callbacks for bridges Frank Li
2024-12-10 22:48 ` [PATCH v8 2/2] PCI: imx6: Add IOMMU and ITS MSI support for i.MX95 Frank Li
2024-12-12 16:46   ` Lorenzo Pieralisi
2024-12-12 17:29     ` Frank Li
2024-12-13  9:32       ` Lorenzo Pieralisi [this message]
2024-12-13 17:20         ` Frank Li
2024-12-17  9:25           ` Lorenzo Pieralisi
2024-12-17 15:50             ` Frank Li
2024-12-27  9:58               ` Lorenzo Pieralisi
2025-01-07 17:03                 ` Frank Li
2025-01-13 22:59                   ` Rob Herring

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=Z1v/LCHsGOgnasuf@lpieralisi \
    --to=lpieralisi@kernel.org \
    --cc=Frank.li@nxp.com \
    --cc=alyssa@rosenzweig.io \
    --cc=bhelgaas@google.com \
    --cc=bpf@vger.kernel.org \
    --cc=broonie@kernel.org \
    --cc=festevam@gmail.com \
    --cc=hongxing.zhu@nxp.com \
    --cc=imx@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=kernel@pengutronix.de \
    --cc=kw@linux.com \
    --cc=l.stach@pengutronix.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=maz@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).