RE: [PATCH 01/37] iommu: Introduce Shared Virtual Addressing API

2018-02-26 Thread Tian, Kevin
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Thursday, February 15, 2018 8:42 PM > > On 13/02/18 23:43, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker > >> Sent: Tuesday, February 13, 2018 8:40 PM > >> > >> > >> [...] > + > +/** > + *

Question on IOMMU indentity mapping for intel-iommu

2018-02-26 Thread Alexander Duyck
I am interested in adding a new memory mapping option that establishes one identity-mapped region for all DMA_TO_DEVICE mappings and creates a new dynamic mapping for any DMA_FROM_DEVICE and DMA_BIDIRECTIONAL mappings. My thought is it should allow for a compromise between security and performance

[PATCH 3/8] arm64: dts: renesas: r8a7795: Set EtherAVB phy mode to "rgmii"

2018-02-26 Thread Jacopo Mondi
Set the "phy-mode" property of EtherAVB device to "rgmii" and let board files override it if the installed PHY layer provides delays for the RX/TX channels. Signed-off-by: Jacopo Mondi --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +- 1 file changed, 1

[PATCH 1/8] arm64: dts: renesas: salvator-common: Override EtherAVB phy-mode

2018-02-26 Thread Jacopo Mondi
As the PHY interface installed on the Salvator-X[S] board, provides TX channel delay, make the "phy-mode" property a board-specific one, meant to override the one specified in the SoC DTSI. Follow up patches will reset the SoC DTSI to use "rgmii" mode and let the board file override that.

[PATCH 2/8] arm64: dts: renesas: r8a7796: Set EtherAVB phy mode to "rgmii"

2018-02-26 Thread Jacopo Mondi
Set the "phy-mode" property of EtherAVB device to "rgmii" and let board files override it if the installed PHY layer provides delays for the RX/TX channels. Signed-off-by: Jacopo Mondi --- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +- 1 file changed, 1

[PATCH 6/8] iommu/ipmmu-vmsa: Hook up R8A77965 DT matching code

2018-02-26 Thread Jacopo Mondi
Add support for R-Car M3-N (R8A77965) SoC IPMMUs. Signed-off-by: Jacopo Mondi --- drivers/iommu/ipmmu-vmsa.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index 933a3da..6a0e714 100644 ---

[PATCH 5/8] dt-bindings: iommu/ipmmu-vmsa: Add R-Car M3-N (R8A77965)

2018-02-26 Thread Jacopo Mondi
Add Renesas R-Car M3-N (R8A77965) compat string to IPMMU DT bindings documentation. Signed-off-by: Jacopo Mondi --- Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 8/8] arm64: dts: renesas: r8a77965: Add EtherAVB device node

2018-02-26 Thread Jacopo Mondi
Populate the ethernet@e680 device node to enable Ethernet interface for R-Car M3-N (R8A77965) SoC. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven --- v1 -> v2: - Replace ALWAYS_ON power area identifier with numeric constant

[PATCH 7/8] arm64: dts: renesas: r8a77965: Add IPMMU mm and ds0 blocks

2018-02-26 Thread Jacopo Mondi
Add IPMMU device nodes for mm and ds0 domains. "ipmmu_ds0" is a dependency for EtherAVB enablement and it has "ipmmu_mm" as it main ipmmu. Signed-off-by: Jacopo Mondi --- arch/arm64/boot/dts/renesas/r8a77965.dtsi | 17 + 1 file changed, 17

[PATCH 4/8] arm64: dts: renesas: r8a77995: Set EtherAVB phy mode to "rgmii"

2018-02-26 Thread Jacopo Mondi
Set the "phy-mode" property of EtherAVB device to "rgmii" and let board files override it if the installed PHY layer provides delays for the RX/TX channels. Signed-off-by: Jacopo Mondi --- arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 +- 1 file changed, 1

[PATCH 0/8] R-Car M3-N: Enable EtherAVB device node

2018-02-26 Thread Jacopo Mondi
Hi Simon, as discussed with you Sergei and Geert, in order to enable EtherAVB for R8A77965 we first wanted to make the phy-mode "rgmii-txid" a board specific property for all other SoCs. This series adds the phy-mode property to salvator-common.dtsi and reset the one for

Re: [PATCH 0/8] R-Car M3-N: Enable EtherAVB device node

2018-02-26 Thread Geert Uytterhoeven
Hi Jacopo, On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi wrote: > as discussed with you Sergei and Geert, in order to enable EtherAVB for > R8A77965 we first wanted to make the phy-mode "rgmii-txid" a board specific > property for all other SoCs. Thanks for your

Re: [PATCH 8/8] arm64: dts: renesas: r8a77965: Add EtherAVB device node

2018-02-26 Thread Geert Uytterhoeven
Hi Jacopo, On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi wrote: > Populate the ethernet@e680 device node to enable Ethernet interface > for R-Car M3-N (R8A77965) SoC. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Geert Uytterhoeven

Re: [PATCH 6/8] iommu/ipmmu-vmsa: Hook up R8A77965 DT matching code

2018-02-26 Thread Geert Uytterhoeven
On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi wrote: > Add support for R-Car M3-N (R8A77965) SoC IPMMUs. > > Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven Gr{oetje,eeting}s,

Re: [PATCH 5/8] dt-bindings: iommu/ipmmu-vmsa: Add R-Car M3-N (R8A77965)

2018-02-26 Thread Geert Uytterhoeven
On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi wrote: > Add Renesas R-Car M3-N (R8A77965) compat string to IPMMU DT bindings > documentation. > > Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven

Re: [PATCH 4/8] arm64: dts: renesas: r8a77995: Set EtherAVB phy mode to "rgmii"

2018-02-26 Thread Geert Uytterhoeven
On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi wrote: > Set the "phy-mode" property of EtherAVB device to "rgmii" and let board > files override it if the installed PHY layer provides delays for the > RX/TX channels. > > Signed-off-by: Jacopo Mondi

Re: [PATCH 3/8] arm64: dts: renesas: r8a7795: Set EtherAVB phy mode to "rgmii"

2018-02-26 Thread Geert Uytterhoeven
On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi wrote: > Set the "phy-mode" property of EtherAVB device to "rgmii" and let board > files override it if the installed PHY layer provides delays for the > RX/TX channels. > > Signed-off-by: Jacopo Mondi

Re: [PATCH 2/8] arm64: dts: renesas: r8a7796: Set EtherAVB phy mode to "rgmii"

2018-02-26 Thread Geert Uytterhoeven
On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi wrote: > Set the "phy-mode" property of EtherAVB device to "rgmii" and let board > files override it if the installed PHY layer provides delays for the > RX/TX channels. > > Signed-off-by: Jacopo Mondi

Re: [PATCH 1/8] arm64: dts: renesas: salvator-common: Override EtherAVB phy-mode

2018-02-26 Thread Geert Uytterhoeven
On Mon, Feb 26, 2018 at 6:57 PM, Jacopo Mondi wrote: > As the PHY interface installed on the Salvator-X[S] board, provides TX > channel delay, make the "phy-mode" property a board-specific one, meant > to override the one specified in the SoC DTSI. > > Follow up patches

Re: [PATCH v2 3/4] iommu/arm-smmu-v3: Support 52-bit physical address

2018-02-26 Thread Will Deacon
On Thu, Dec 14, 2017 at 04:58:52PM +, Robin Murphy wrote: > Implement SMMUv3.1 support for 52-bit physical addresses. Since a 52-bit > OAS implies 64KB translation granule support, permitting level 1 block > entries there is simple, and the rest is just extending address fields. > >

Re: [PATCH v2 4/4] iommu/arm-smmu-v3: Support 52-bit virtual address

2018-02-26 Thread Will Deacon
On Thu, Dec 14, 2017 at 04:58:53PM +, Robin Murphy wrote: > Stage 1 input addresses are effectively 64-bit in SMMUv3 anyway, so > really all that's involved is letting io-pgtable know the appropriate > upper bound for T0SZ. > > Tested-by: Nate Watterson >

Re: [PATCH v2 2/4] iommu/io-pgtable-arm: Support 52-bit physical address

2018-02-26 Thread Will Deacon
On Thu, Dec 14, 2017 at 04:58:51PM +, Robin Murphy wrote: > Bring io-pgtable-arm in line with the ARMv8.2-LPA feature allowing > 52-bit physical addresses when using the 64KB translation granule. > This will be supported by SMMUv3.1. > > Tested-by: Nate Watterson >

Re: [PATCH v2 1/4] iommu/arm-smmu-v3: Clean up address masking

2018-02-26 Thread Will Deacon
Hi Robin, On Thu, Dec 14, 2017 at 04:58:50PM +, Robin Murphy wrote: > Before trying to add the SMMUv3.1 support for 52-bit addresses, make > things bearable by cleaning up the various address mask definitions to > use GENMASK_ULL() consistently. The fact that doing so reveals (and > fixes) a

Re: [PATCH v2 0/4] SMMU 52-bit address support

2018-02-26 Thread Will Deacon
Hi Robin, On Thu, Dec 14, 2017 at 04:58:49PM +, Robin Murphy wrote: > Here's a (hopefully final) update of 52-bit SMMU support. The only > material changes from v1[1] are a small cosmetic tweak to patch #1, > and correction of the silly error in patch #2 as reported by Nate in > testing.