From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Clark Subject: Re: [PATCH 3/3] ARM64: DT: add iommu for msm8916 Date: Wed, 31 May 2017 07:58:16 -0400 Message-ID: References: <20170525174822.27996-1-robdclark@gmail.com> <20170525174822.27996-4-robdclark@gmail.com> <20170531001435.GR20170@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from mail-lf0-f65.google.com ([209.85.215.65]:35384 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751060AbdEaL6S (ORCPT ); Wed, 31 May 2017 07:58:18 -0400 Received: by mail-lf0-f65.google.com with SMTP id 99so1171944lfu.2 for ; Wed, 31 May 2017 04:58:17 -0700 (PDT) In-Reply-To: <20170531001435.GR20170@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Stephen Boyd Cc: linux-arm-msm , Andy Gross , Stanimir Varbanov On Tue, May 30, 2017 at 8:14 PM, Stephen Boyd wrote: > On 05/25, Rob Clark wrote: >> + apps_iommu: iommu@1ef0000 { >> + #address-cells = <1>; >> + #size-cells = <1>; >> + #iommu-cells = <1>; >> + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; >> + ranges = <0 0x1e20000 0x40000>; >> + reg = <0x1ef0000 0x3000>; >> + clocks = <&gcc GCC_SMMU_CFG_CLK>, >> + <&gcc GCC_APSS_TCU_CLK>; >> + clock-names = "iface", "bus"; >> + qcom,iommu-secure-id = <17>; >> + >> + // mdp_0: >> + iommu-ctx@4000 { >> + compatible = "qcom,msm-iommu-v1-ns"; >> + reg = <0x4000 0x1000>; >> + interrupts = ; > > s/0/IRQ_TYPE_LEVEL_HIGH/ 0 actually seems to be _NONE.. so using _HIGH would change how irq is configured (according to gic_configure_irq()). Do you expect that to work? I'm probably going based on what was in downstream dt, and some of that is more a pain to retest so I'd rather not change the type unless at least one of us knows what they are doing. >> + }; >> + >> + // venus_ns: >> + iommu-ctx@5000 { >> + compatible = "qcom,msm-iommu-v1-sec"; >> + reg = <0x5000 0x1000>; >> + interrupts = ; > > s/0/IRQ_TYPE_LEVEL_HIGH/ > > Is it the same interrupt number (70) twice? Not 71 or something? According to downstream. Not *entirely* sure how that is supposed to work as far as dispatching fault callback to the right driver, but at least unlike with the gpu, if we get a fault for mdp, that is entirely the kernels fault. So meh? If you know better, let me know. BR, -R > >> + }; >> + }; >> + >> + gpu_iommu: iommu@1f08000 { >> + #address-cells = <1>; >> + #size-cells = <1>; >> + #iommu-cells = <1>; >> + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; >> + ranges = <0 0x1f08000 0x10000>; >> + clocks = <&gcc GCC_SMMU_CFG_CLK>, >> + <&gcc GCC_GFX_TCU_CLK>; >> + clock-names = "iface", "bus"; >> + qcom,iommu-secure-id = <18>; >> + >> + // gfx3d_user: >> + iommu-ctx@1000 { >> + compatible = "qcom,msm-iommu-v1-ns"; >> + reg = <0x1000 0x1000>; >> + interrupts = ; > > s/0/IRQ_TYPE_LEVEL_HIGH/ > >> + }; >> + >> + // gfx3d_priv: >> + iommu-ctx@2000 { >> + compatible = "qcom,msm-iommu-v1-ns"; >> + reg = <0x2000 0x1000>; >> + interrupts = ; > > s/0/IRQ_TYPE_LEVEL_HIGH/ > >> + }; >> + }; >> + >> gpu_opp_table: opp_table { >> compatible = "operating-points-v2"; >> > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project