All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	magnus.damm@gmail.com, linux-renesas-soc@vger.kernel.org,
	linux-pci <linux-pci@vger.kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH v2] arm64: dts: renesas: Add IOMMU related properties into PCIe host nodes
Date: Thu, 4 May 2023 13:10:12 +0530	[thread overview]
Message-ID: <20230504074012.GA4162@thinkpad> (raw)
In-Reply-To: <CAMuHMdXBq0XZwgSUTQSrdYiQ0C0WBaHETqNLfF766TiXoCkKhg@mail.gmail.com>

On Wed, May 03, 2023 at 02:38:49PM +0200, Geert Uytterhoeven wrote:
> Hi Shimoda-san,
> 
> CC linux-pci
> 
> On Wed, Apr 26, 2023 at 10:28 AM Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com> wrote:
> > Add iommu-map and iommu-map-mask properties into PCIe host nodes.
> > Note that iommu-map-mask should be zero because the IPMMU assigns
> > one micro TLB ID only to the PCIe host.
> >

What do you mean by "only to the PCIe host"? Are you referring to the host
bridge in the SoC?

> > Also change dma-ranges arguments for IOMMU. Notes that the dma-ranges
> > can be used if IOMMU is disabled.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> 
> Thanks for your patch!
> 
> This is not really my area of expertise, but you can still find some
> questions and comments below...
> 
> > ---
> >  Changes from v1:
> > https://lore.kernel.org/all/20230421122608.3389397-1-yoshihiro.shimoda.uh@renesas.com/
> >  - Drop iommus property.
> >  - Add iommu-map-mask property.
> >  - Revise the commit description.
> >
> >  arch/arm64/boot/dts/renesas/r8a77951.dtsi | 12 ++++++++----
> >  arch/arm64/boot/dts/renesas/r8a77960.dtsi | 12 ++++++++----
> >  arch/arm64/boot/dts/renesas/r8a77961.dtsi | 12 ++++++++----
> >  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 12 ++++++++----
> >  arch/arm64/boot/dts/renesas/r8a77990.dtsi |  6 ++++--
> >  5 files changed, 36 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77951.dtsi b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
> > index 10b91e9733bf..2adec8b6c93f 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
> > @@ -2778,8 +2778,8 @@ pciec0: pcie@fe000000 {
> >                                  <0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000>,
> >                                  <0x02000000 0 0x30000000 0 0x30000000 0 0x08000000>,
> >                                  <0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
> > -                       /* Map all possible DDR as inbound ranges */
> > -                       dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000>;
> > +                       /* Map all possible DDR/IOMMU as inbound ranges */
> > +                       dma-ranges = <0x42000000 0 0x00000000 0 0x00000000 1 0x00000000>;
> 
> So this is limited to the first 4 GiB of DDR (DDR0), i.e. to 32-bit
> address space? Shouldn't this include DDR1/2/3?
> 
> >                         interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
> >                                 <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
> >                                 <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> > @@ -2790,6 +2790,8 @@ pciec0: pcie@fe000000 {
> >                         clock-names = "pcie", "pcie_bus";
> >                         power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> >                         resets = <&cpg 319>;
> > +                       iommu-map = <0 &ipmmu_hc 0 0x10000>;
> 
> Reading
> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/pci/pci-iommu.txt#L35
> the above means you map 65536 RIDs n in the range 0..65535
> to  <&ipmmu_hc n>, while only micro-TLBs 0 and 1 are assigned to PCIe?
> 
> Hence I think this should be:
> 
>     iommu-map = <0 &ipmmu_hc 0 1>;
> 

If there are no PCI-PCI bridges in the SoC, then the devices connected to the
host bridge should share the same bus number i.e., 00:00.0 to 00.1f.8. In that
case, you should have the iommu-map as per Geert's suggestion. Paired with
iommu-map-mask of 0, this implies that all the devices and functions of bus 0
will share the same RID.

This holds true for other instance as well.

- Mani

> > +                       iommu-map-mask = <0>;
> >                         status = "disabled";
> >                 };
> >
> > @@ -2805,8 +2807,8 @@ pciec1: pcie@ee800000 {
> >                                  <0x02000000 0 0xeea00000 0 0xeea00000 0 0x00200000>,
> >                                  <0x02000000 0 0xc0000000 0 0xc0000000 0 0x08000000>,
> >                                  <0x42000000 0 0xc8000000 0 0xc8000000 0 0x08000000>;
> > -                       /* Map all possible DDR as inbound ranges */
> > -                       dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000>;
> > +                       /* Map all possible DDR/IOMMU as inbound ranges */
> > +                       dma-ranges = <0x42000000 0 0x00000000 0 0x00000000 1 0x00000000>;
> 
> Likewise.
> 
> >                         interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
> >                                 <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
> >                                 <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
> > @@ -2817,6 +2819,8 @@ pciec1: pcie@ee800000 {
> >                         clock-names = "pcie", "pcie_bus";
> >                         power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> >                         resets = <&cpg 318>;
> > +                       iommu-map = <0 &ipmmu_hc 1 0x10000>;
> 
> Likewise, the above means you map 65536 RIDs n in the range 0..65535
> to  <&ipmmu_hc (1 + n)>?
> 
> Hence I think this should be:
> 
>     iommu-map = <0 &ipmmu_hc 1 1>;
> 
> > +                       iommu-map-mask = <0>;
> >                         status = "disabled";
> >                 };
> 
> Same comment for all other changes.
> 
> In addition, we need similar changes to r8a774{a1,b1,c0,e1}.dtsi,
> and slightly different changes (using ipmmu_vi0 uTLB 5) to r8a77980.dtsi.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

-- 
மணிவண்ணன் சதாசிவம்

  reply	other threads:[~2023-05-04  7:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-26  8:28 [PATCH v2] arm64: dts: renesas: Add IOMMU related properties into PCIe host nodes Yoshihiro Shimoda
2023-05-03 12:38 ` Geert Uytterhoeven
2023-05-04  7:40   ` Manivannan Sadhasivam [this message]
2023-05-08 12:09     ` Yoshihiro Shimoda
2023-05-08 12:02   ` Yoshihiro Shimoda

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=20230504074012.GA4162@thinkpad \
    --to=manivannan.sadhasivam@linaro.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=yoshihiro.shimoda.uh@renesas.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.