Hi Magnus,
On Thu, May 24, 2018 at 10:18 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
> On Thu, May 24, 2018 at 4:25 PM, Geert Uytterhoeven
> <geert@xxxxxxxxxxxxxx> wrote:
>> On Thu, May 24, 2018 at 4:23 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
>>> On Tue, May 22, 2018 at 10:10 PM, Simon Horman <horms@xxxxxxxxxxxx> wrote:
>>>> On Mon, May 21, 2018 at 11:45:01PM +0900, Magnus Damm wrote:
>>>>> From: Magnus Damm <damm+renesas@xxxxxxxxxxxxx>
>>>>>
>>>>> Add IPMMU device nodes for the R-Car V3H SoC aka r8a77980.
>>>>>
>>>>> The r8a77980 IPMMU is quite similar to r8a77970 however VC0
>>>>> has been added. The IMSSTR bit assignment has also been
>>>>> reworked. Power domains are also quite different however the
>>>>> the documentation is rather unclear about this topic.
>>>>>
>>>>> Until we know better VC0 gets assigned to R8A77980_PD_ALWAYS_ON.
>>>>>
>>>>> Signed-off-by: Magnus Damm <damm+renesas@xxxxxxxxxxxxx>
>>>>> ---
>>>>>
>>>>> Developed on top of renesas-devel-20180518-v4.17-rc5
>>>>>
>>>>> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 49 +++++++++++++++++++++++++++++
>>>>> 1 file changed, 49 insertions(+)
>>>>>
>>>>> --- 0001/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>>>>> +++ work/arch/arm64/boot/dts/renesas/r8a77980.dtsi 2018-05-21 22:31:52.460607110 +0900
>>>>> @@ -387,6 +387,55 @@
>>>>> dma-channels = <16>;
>>>>> };
>>>>>
>>>>> + ipmmu_ds1: mmu@e7740000 {
>>>>> + compatible = "renesas,ipmmu-r8a77980";
>>>>> + reg = <0 0xe7740000 0 0x1000>;
>>>>> + renesas,ipmmu-main = <&ipmmu_mm 0>;
>>>>> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
>>>>> + #iommu-cells = <1>;
>>>>> + };
>>>>> +
>>>>> + ipmmu_ir: mmu@ff8b0000 {
>>>>> + compatible = "renesas,ipmmu-r8a77980";
>>>>> + reg = <0 0xff8b0000 0 0x1000>;
>>>>> + renesas,ipmmu-main = <&ipmmu_mm 3>;
>>>>> + power-domains = <&sysc R8A77980_PD_A3IR>;
>>>>> + #iommu-cells = <1>;
>>>>> + };
>>>>> +
>>>>> + ipmmu_mm: mmu@e67b0000 {
>>>>> + compatible = "renesas,ipmmu-r8a77980";
>>>>> + reg = <0 0xe67b0000 0 0x1000>;
>>>>> + interrupts = <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
>>>>> + <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>;
>>>>> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
>>>>> + #iommu-cells = <1>;
>>>>> + };
>>>>> +
>>>>> + ipmmu_rt: mmu@ffc80000 {
>>>>> + compatible = "renesas,ipmmu-r8a77980";
>>>>> + reg = <0 0xffc80000 0 0x1000>;
>>>>> + renesas,ipmmu-main = <&ipmmu_mm 10>;
>>>>> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
>>>>> + #iommu-cells = <1>;
>>>>> + };
>>>>> +
>>>>> + ipmmu_vc0: mmu@fe6b0000 {
>>>>> + compatible = "renesas,ipmmu-r8a77980";
>>>>> + reg = <0 0xfe6b0000 0 0x1000>;
>>>>> + renesas,ipmmu-main = <&ipmmu_mm 12>;
>>>>> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
>>>>> + #iommu-cells = <1>;
>>>>> + };
>>>>> +
>>>>> + ipmmu_vi0: mmu@febd0000 {
>>>>> + compatible = "renesas,ipmmu-r8a77980";
>>>>> + reg = <0 0xfebd0000 0 0x1000>;
>>>>> + renesas,ipmmu-main = <&ipmmu_mm 14>;
>>>>> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
>>>>> + #iommu-cells = <1>;
>>>>> + };
>>>>> +
>>>>
>>>> nit: I believe the IPMMU nodes should go above the AVB rather than the
>>>> MMC node to preserve the current node sorting order of:
>>>>
>>>> 1) bus address
>>>> 2) IP block
>>>> 3) alphabetical
>>>
>>> Will reposition the IPMMU nodes in next version. Will also add vip0
>>> and vip1 IPMMU nodes as described in the 1.0 data sheet.
>>
>> Note that the BSP has patches to move the ipmmu_mm nodes first, to
>> work around probe order issues.
>
> That might have been appropriate for older IPMMU driver versions.
>
> I think what is in upstream should not depend on any ordering.
I don't know, it's an -EPROBE_DEFER issue.
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=903fa7776d24a095ecbbbc44c12cabcc096d88a6
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
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
