From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7ADA5C433DB for ; Thu, 11 Mar 2021 23:30:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 48DAA64F95 for ; Thu, 11 Mar 2021 23:30:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230406AbhCKX3v (ORCPT ); Thu, 11 Mar 2021 18:29:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230388AbhCKX32 (ORCPT ); Thu, 11 Mar 2021 18:29:28 -0500 Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74BEDC061760 for ; Thu, 11 Mar 2021 15:29:28 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id f73-20020a9d03cf0000b02901b4d889bce0so491583otf.12 for ; Thu, 11 Mar 2021 15:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=491rIB6TbnxYKUbmp43lo7687n1uls9e/9Yv3zZ/+/M=; b=SMNVB6H5xpNSP+Ntt/E41bnstJS/mub/pjKkhJYxD/9m/0JdTt1Sc/JeacWsclnhIa saZlM35oEZUGd6GLJc1B0Z8fOHlmarLVRa320OirgMyuk3CMzsKTN3VBH5KUOauAu923 d2ymYxIDPYCBsoGohPV+44DV5Vg2pH3P1pSno36NGadsaTHK9d6OhoL/AnG1QXTXQjq6 WfezMMjeqBUM6N2bVJmXtEz+LPF75d9wrFoBjlOAkTBvA8q7hY2kgy7D9mi3SqDP3npX UArOx0eMWnVGobKk8hawyEDO7rE3C0zoYDGB3jhrj15GrhugPdE6laoOn+2Xy00KuXrQ srhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=491rIB6TbnxYKUbmp43lo7687n1uls9e/9Yv3zZ/+/M=; b=SsXoaLp98+wCnhofzX7RpHKCltUHFXHipzKl4ReSecBqN/6Uk3GG4Unsu7hBpVIHyf RiH7CLMYuSXD93VyobUPaBaZHVpG3agLbILw//hWw97bkvhobI4iKARl+Xv8En2NssFl d5ePLMmf+nQTSgbuOH7rQnxLaOksAPYkyjkF9ea3o/wW9WJ+dfFkDsZMP0kjE/6JiUcr DDlf9KisYxXkeGJfpO2gHu2S60ol42Ff/EOh4sLFLfIKq7Qiuu0MHQKmkWEOqtFG/HAJ 9uvJPWgX1ykpSlJPa7mBJ9ql44U4v35GNx5S1MNXPoHhwIYF6ygpxv+xps2en6WeDt8W RuPA== X-Gm-Message-State: AOAM532QWESyD7Rxnzkkya8uCArSeDsfbVYKzFrHuSiPKWKYiF01Vbts x1HELxD0tc5chSUhblyI15AE1A== X-Google-Smtp-Source: ABdhPJw4KQvalKBsueb6g3JYuyjaH1gcgChPlIne9ccF8RDotEH2OI5ha3PVdoOKbRbxK7d39hmllA== X-Received: by 2002:a05:6830:101a:: with SMTP id a26mr1116383otp.68.1615505367766; Thu, 11 Mar 2021 15:29:27 -0800 (PST) Received: from builder.lan (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id l190sm639403oig.39.2021.03.11.15.29.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Mar 2021 15:29:27 -0800 (PST) Date: Thu, 11 Mar 2021 17:29:25 -0600 From: Bjorn Andersson To: Sai Prakash Ranjan Cc: akhilpo@codeaurora.org, iommu@lists.linux-foundation.org, jcrouse@codeaurora.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, robdclark@gmail.com, robin.murphy@arm.com, will@kernel.org Subject: Re: [PATCHv2 2/2] iommu/arm-smmu-qcom: Move the adreno smmu specific impl earlier Message-ID: References: <20210227135321.420-1-saiprakash.ranjan@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210227135321.420-1-saiprakash.ranjan@codeaurora.org> Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Sat 27 Feb 07:53 CST 2021, Sai Prakash Ranjan wrote: > Hi Bjorn, > > On 2021-02-27 00:44, Bjorn Andersson wrote: > > On Fri 26 Feb 12:23 CST 2021, Rob Clark wrote: > > > > > > The current logic picks one of: > > 1) is the compatible mentioned in qcom_smmu_impl_of_match[] > > 2) is the compatible an adreno > > 3) no quirks needed > > > > The change flips the order of these, so the only way I can see this > > change affecting things is if we expected a match on #2, but we got one > > on #1. > > > > Which implies that the instance that we want to act according to the > > adreno impl was listed in qcom_smmu_impl_of_match[] - which either is > > wrong, or there's a single instance that needs both behaviors. > > > > (And I believe Jordan's answer confirms the latter - there's a single > > SMMU instance that needs all them quirks at once) > > > > Let me go through the problem statement in case my commit message wasn't > clear. There are two SMMUs (APSS and GPU) on SC7280 and both are SMMU500 > (ARM SMMU IP). > > APSS SMMU compatible - ("qcom,sc7280-smmu-500", "arm,mmu-500") > GPU SMMU compatible - ("qcom,sc7280-smmu-500", "qcom,adreno-smmu", "arm,mmu-500") > > Now if we take SC7180 as an example, GPU SMMU was QSMMU(QCOM SMMU IP) > and APSS SMMU was SMMU500(ARM SMMU IP). > > APSS SMMU compatible - ("qcom,sc7180-smmu-500", "arm,mmu-500") > GPU SMMU compatible - ("qcom,sc7180-smmu-v2", "qcom,adreno-smmu", "qcom,smmu-v2") > > Current code sequence without this patch, > > if (of_match_node(qcom_smmu_impl_of_match, np)) > return qcom_smmu_create(smmu, &qcom_smmu_impl); > > if (of_device_is_compatible(np, "qcom,adreno-smmu")) > return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl); > > Now if we look at the compatible for SC7180, there is no problem because > the APSS SMMU will match the one in qcom_smmu_impl_of_match[] and GPU SMMU > will match "qcom,adreno-smmu" because the compatible strings are different. > But for SC7280, both the APSS SMMU and GPU SMMU compatible("qcom,sc7280-smmu-500") > are same. So GPU SMMU will match with the one in qcom_smmu_impl_of_match[] > i.e.., "qcom,sc7280-smmu-500" which functionally doesn't cause any problem > but we will miss settings for split pagetables which are part of GPU SMMU > specific implementation. > > We can avoid this with yet another new compatible for GPU SMMU something like > "qcom,sc7280-adreno-smmu-500" but since we can handle this easily in the > driver and since the IPs are same, meaning if there was a hardware quirk > required, then we would need to apply to both of them and would this additional > compatible be of any help? > No, I think you're doing the right thing of having them both. I just didn't remember us doing that. > Coming to the part of quirks now, you are right saying both SMMUs will need > to have the same quirks in SC7280 and similar others where both are based on > same IPs but those should probably be *hardware quirks* and if they are > software based like the S2CR quirk depending on the firmware, then it might > not be applicable to both. In case if it is applicable, then as Jordan mentioned, > we can add the same quirks in GPU SMMU implementation. > I do suspect that at some point (probably sooner than later) we'd have to support both inheriting of stream from the bootloader and the Adreno "quirks" in the same instance. But for now this is okay to me. Regards, Bjorn From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4361CC433E0 for ; Thu, 11 Mar 2021 23:29:34 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A642664F94 for ; Thu, 11 Mar 2021 23:29:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A642664F94 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 58CFD6F95F; Thu, 11 Mar 2021 23:29:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scoiJ67idIHQ; Thu, 11 Mar 2021 23:29:31 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp3.osuosl.org (Postfix) with ESMTP id 7B246606E4; Thu, 11 Mar 2021 23:29:31 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 521BAC000B; Thu, 11 Mar 2021 23:29:31 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id CC1AEC0001 for ; Thu, 11 Mar 2021 23:29:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id BA22E6F940 for ; Thu, 11 Mar 2021 23:29:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2jhMMcAH0Nv for ; Thu, 11 Mar 2021 23:29:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) by smtp3.osuosl.org (Postfix) with ESMTPS id CB9AC606E4 for ; Thu, 11 Mar 2021 23:29:28 +0000 (UTC) Received: by mail-ot1-x334.google.com with SMTP id 75so2692370otn.4 for ; Thu, 11 Mar 2021 15:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=491rIB6TbnxYKUbmp43lo7687n1uls9e/9Yv3zZ/+/M=; b=SMNVB6H5xpNSP+Ntt/E41bnstJS/mub/pjKkhJYxD/9m/0JdTt1Sc/JeacWsclnhIa saZlM35oEZUGd6GLJc1B0Z8fOHlmarLVRa320OirgMyuk3CMzsKTN3VBH5KUOauAu923 d2ymYxIDPYCBsoGohPV+44DV5Vg2pH3P1pSno36NGadsaTHK9d6OhoL/AnG1QXTXQjq6 WfezMMjeqBUM6N2bVJmXtEz+LPF75d9wrFoBjlOAkTBvA8q7hY2kgy7D9mi3SqDP3npX UArOx0eMWnVGobKk8hawyEDO7rE3C0zoYDGB3jhrj15GrhugPdE6laoOn+2Xy00KuXrQ srhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=491rIB6TbnxYKUbmp43lo7687n1uls9e/9Yv3zZ/+/M=; b=F0yiff50KF4LSyIlBJjYLKsvKbNFUEp747r+NPbCDe30tXZQjLzdvgA/pi7DMX5lcN 5LkUUit7byo25tg9Jmi6d+i6gXFv5TyvjpsyhNc9PbMOY7fadZk8TJeD83Dk0i7mQyEM dtu9OobYL43v03/i4jY32Q69BNYsKXplTBhqemCFVXiy8WQi1laWlmNQ1NNSW1b1w2At /VVx0ugeOFt7eKuhyKAU4Me+GDO4Fvr9XQMd9l3L+UTIozIWui66+IQyHIgZ2tiPyQ5U fcwXR6HIKmIO+hospPYJ8ClyUcTcZCUBJ6FnW+U+Y4fAMip37HBFkrvBykM0e+E9iF6x qRSw== X-Gm-Message-State: AOAM531IyCodni+cGb0zEhNNY40NSV/cRYuOLk7GF5WQJbonhCsR7I/L ymgwwJliY22fG+8GKE0NvPxK2w== X-Google-Smtp-Source: ABdhPJw4KQvalKBsueb6g3JYuyjaH1gcgChPlIne9ccF8RDotEH2OI5ha3PVdoOKbRbxK7d39hmllA== X-Received: by 2002:a05:6830:101a:: with SMTP id a26mr1116383otp.68.1615505367766; Thu, 11 Mar 2021 15:29:27 -0800 (PST) Received: from builder.lan (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id l190sm639403oig.39.2021.03.11.15.29.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Mar 2021 15:29:27 -0800 (PST) Date: Thu, 11 Mar 2021 17:29:25 -0600 From: Bjorn Andersson To: Sai Prakash Ranjan Subject: Re: [PATCHv2 2/2] iommu/arm-smmu-qcom: Move the adreno smmu specific impl earlier Message-ID: References: <20210227135321.420-1-saiprakash.ranjan@codeaurora.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210227135321.420-1-saiprakash.ranjan@codeaurora.org> Cc: linux-kernel@vger.kernel.org, will@kernel.org, linux-arm-msm@vger.kernel.org, jcrouse@codeaurora.org, akhilpo@codeaurora.org, iommu@lists.linux-foundation.org, robin.murphy@arm.com, linux-arm-kernel@lists.infradead.org X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Sat 27 Feb 07:53 CST 2021, Sai Prakash Ranjan wrote: > Hi Bjorn, > > On 2021-02-27 00:44, Bjorn Andersson wrote: > > On Fri 26 Feb 12:23 CST 2021, Rob Clark wrote: > > > > > > The current logic picks one of: > > 1) is the compatible mentioned in qcom_smmu_impl_of_match[] > > 2) is the compatible an adreno > > 3) no quirks needed > > > > The change flips the order of these, so the only way I can see this > > change affecting things is if we expected a match on #2, but we got one > > on #1. > > > > Which implies that the instance that we want to act according to the > > adreno impl was listed in qcom_smmu_impl_of_match[] - which either is > > wrong, or there's a single instance that needs both behaviors. > > > > (And I believe Jordan's answer confirms the latter - there's a single > > SMMU instance that needs all them quirks at once) > > > > Let me go through the problem statement in case my commit message wasn't > clear. There are two SMMUs (APSS and GPU) on SC7280 and both are SMMU500 > (ARM SMMU IP). > > APSS SMMU compatible - ("qcom,sc7280-smmu-500", "arm,mmu-500") > GPU SMMU compatible - ("qcom,sc7280-smmu-500", "qcom,adreno-smmu", "arm,mmu-500") > > Now if we take SC7180 as an example, GPU SMMU was QSMMU(QCOM SMMU IP) > and APSS SMMU was SMMU500(ARM SMMU IP). > > APSS SMMU compatible - ("qcom,sc7180-smmu-500", "arm,mmu-500") > GPU SMMU compatible - ("qcom,sc7180-smmu-v2", "qcom,adreno-smmu", "qcom,smmu-v2") > > Current code sequence without this patch, > > if (of_match_node(qcom_smmu_impl_of_match, np)) > return qcom_smmu_create(smmu, &qcom_smmu_impl); > > if (of_device_is_compatible(np, "qcom,adreno-smmu")) > return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl); > > Now if we look at the compatible for SC7180, there is no problem because > the APSS SMMU will match the one in qcom_smmu_impl_of_match[] and GPU SMMU > will match "qcom,adreno-smmu" because the compatible strings are different. > But for SC7280, both the APSS SMMU and GPU SMMU compatible("qcom,sc7280-smmu-500") > are same. So GPU SMMU will match with the one in qcom_smmu_impl_of_match[] > i.e.., "qcom,sc7280-smmu-500" which functionally doesn't cause any problem > but we will miss settings for split pagetables which are part of GPU SMMU > specific implementation. > > We can avoid this with yet another new compatible for GPU SMMU something like > "qcom,sc7280-adreno-smmu-500" but since we can handle this easily in the > driver and since the IPs are same, meaning if there was a hardware quirk > required, then we would need to apply to both of them and would this additional > compatible be of any help? > No, I think you're doing the right thing of having them both. I just didn't remember us doing that. > Coming to the part of quirks now, you are right saying both SMMUs will need > to have the same quirks in SC7280 and similar others where both are based on > same IPs but those should probably be *hardware quirks* and if they are > software based like the S2CR quirk depending on the firmware, then it might > not be applicable to both. In case if it is applicable, then as Jordan mentioned, > we can add the same quirks in GPU SMMU implementation. > I do suspect that at some point (probably sooner than later) we'd have to support both inheriting of stream from the bootloader and the Adreno "quirks" in the same instance. But for now this is okay to me. Regards, Bjorn _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 277DDC433DB for ; Thu, 11 Mar 2021 23:31:38 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AA47864F93 for ; Thu, 11 Mar 2021 23:31:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA47864F93 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=o+UsHjGc4fq86LRRYSXgyVM3TWRelOsuYjSd7Usm1Q8=; b=lny7BMgQygnNwtelbWbKvT7P2 OmaPhG7kno4Byx3xt7t/fKFNKk+cjSOQQxMToqtNkSDF9YDEbETBpI/SVWJH5SOtgbTsZgq+AKeHc 7Xx/+hgrvEfdzkwOH9XaJ5NOoLDqi2pr2Uil071YU8yj0d+/vDihZyrRqcAv0IxmP7/pg6B1urpXw juPuH8FGoRvx3XnMVJQNaTzVeGgC6fCEeE80Zans2DFtdsrn+WQJ68szKx4YgP6qgJrGP+33wnq7g d9ukJ9NbvS3tX/EcHzfvgcbe5Q6i5QOXqjJ8fToz4C3boLWnr41C9jsTlO/t8gNazTdkE6KaTgpHh vOglnBK4w==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lKUkP-00AEI3-LH; Thu, 11 Mar 2021 23:29:41 +0000 Received: from mail-ot1-x333.google.com ([2607:f8b0:4864:20::333]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lKUkE-00AEGE-4W for linux-arm-kernel@lists.infradead.org; Thu, 11 Mar 2021 23:29:33 +0000 Received: by mail-ot1-x333.google.com with SMTP id r24so2659976otq.13 for ; Thu, 11 Mar 2021 15:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=491rIB6TbnxYKUbmp43lo7687n1uls9e/9Yv3zZ/+/M=; b=SMNVB6H5xpNSP+Ntt/E41bnstJS/mub/pjKkhJYxD/9m/0JdTt1Sc/JeacWsclnhIa saZlM35oEZUGd6GLJc1B0Z8fOHlmarLVRa320OirgMyuk3CMzsKTN3VBH5KUOauAu923 d2ymYxIDPYCBsoGohPV+44DV5Vg2pH3P1pSno36NGadsaTHK9d6OhoL/AnG1QXTXQjq6 WfezMMjeqBUM6N2bVJmXtEz+LPF75d9wrFoBjlOAkTBvA8q7hY2kgy7D9mi3SqDP3npX UArOx0eMWnVGobKk8hawyEDO7rE3C0zoYDGB3jhrj15GrhugPdE6laoOn+2Xy00KuXrQ srhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=491rIB6TbnxYKUbmp43lo7687n1uls9e/9Yv3zZ/+/M=; b=SFo15vIL2PibxAkMSIpn3JObpztEwyfHwaPwcegmFlzCrxCgeeMUUKjbv1FpvmW1bX UAeGVsDrgiQRGRYfQSs8mX8iwV7Ycp2FY1hLEDTUQ3h505AXUo2u90cbGkSycW4gAZSX Xxsgx8yfhe1NS79Fpg0rdWU+Q08U7tSsh7ySNfFdp35LdQqpQ1PR9YBgAVxxcPE4kTn4 0KDVhbmvVl1aaewTCm0TNtyeYHg7MBI/x3uPlyBokPO7D/cnPabtwOlFH5koR7pSAOD4 N08Xmi8JHtw+FlEuDqGYG0BXavj5+Xn9ZF4c2QWGFjWDTYiqsfKd/GgTnOZaAsHvbrMZ MEjA== X-Gm-Message-State: AOAM532tMhH3xFn22/Cnd6famYJB+o3sE3It5B3pbuleLczneDAyVSwp wEe83UGdQrhtceMGymXgkMWyIw== X-Google-Smtp-Source: ABdhPJw4KQvalKBsueb6g3JYuyjaH1gcgChPlIne9ccF8RDotEH2OI5ha3PVdoOKbRbxK7d39hmllA== X-Received: by 2002:a05:6830:101a:: with SMTP id a26mr1116383otp.68.1615505367766; Thu, 11 Mar 2021 15:29:27 -0800 (PST) Received: from builder.lan (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id l190sm639403oig.39.2021.03.11.15.29.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Mar 2021 15:29:27 -0800 (PST) Date: Thu, 11 Mar 2021 17:29:25 -0600 From: Bjorn Andersson To: Sai Prakash Ranjan Cc: akhilpo@codeaurora.org, iommu@lists.linux-foundation.org, jcrouse@codeaurora.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, robdclark@gmail.com, robin.murphy@arm.com, will@kernel.org Subject: Re: [PATCHv2 2/2] iommu/arm-smmu-qcom: Move the adreno smmu specific impl earlier Message-ID: References: <20210227135321.420-1-saiprakash.ranjan@codeaurora.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210227135321.420-1-saiprakash.ranjan@codeaurora.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210311_232930_851433_D3A99C7F X-CRM114-Status: GOOD ( 31.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat 27 Feb 07:53 CST 2021, Sai Prakash Ranjan wrote: > Hi Bjorn, > > On 2021-02-27 00:44, Bjorn Andersson wrote: > > On Fri 26 Feb 12:23 CST 2021, Rob Clark wrote: > > > > > > The current logic picks one of: > > 1) is the compatible mentioned in qcom_smmu_impl_of_match[] > > 2) is the compatible an adreno > > 3) no quirks needed > > > > The change flips the order of these, so the only way I can see this > > change affecting things is if we expected a match on #2, but we got one > > on #1. > > > > Which implies that the instance that we want to act according to the > > adreno impl was listed in qcom_smmu_impl_of_match[] - which either is > > wrong, or there's a single instance that needs both behaviors. > > > > (And I believe Jordan's answer confirms the latter - there's a single > > SMMU instance that needs all them quirks at once) > > > > Let me go through the problem statement in case my commit message wasn't > clear. There are two SMMUs (APSS and GPU) on SC7280 and both are SMMU500 > (ARM SMMU IP). > > APSS SMMU compatible - ("qcom,sc7280-smmu-500", "arm,mmu-500") > GPU SMMU compatible - ("qcom,sc7280-smmu-500", "qcom,adreno-smmu", "arm,mmu-500") > > Now if we take SC7180 as an example, GPU SMMU was QSMMU(QCOM SMMU IP) > and APSS SMMU was SMMU500(ARM SMMU IP). > > APSS SMMU compatible - ("qcom,sc7180-smmu-500", "arm,mmu-500") > GPU SMMU compatible - ("qcom,sc7180-smmu-v2", "qcom,adreno-smmu", "qcom,smmu-v2") > > Current code sequence without this patch, > > if (of_match_node(qcom_smmu_impl_of_match, np)) > return qcom_smmu_create(smmu, &qcom_smmu_impl); > > if (of_device_is_compatible(np, "qcom,adreno-smmu")) > return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl); > > Now if we look at the compatible for SC7180, there is no problem because > the APSS SMMU will match the one in qcom_smmu_impl_of_match[] and GPU SMMU > will match "qcom,adreno-smmu" because the compatible strings are different. > But for SC7280, both the APSS SMMU and GPU SMMU compatible("qcom,sc7280-smmu-500") > are same. So GPU SMMU will match with the one in qcom_smmu_impl_of_match[] > i.e.., "qcom,sc7280-smmu-500" which functionally doesn't cause any problem > but we will miss settings for split pagetables which are part of GPU SMMU > specific implementation. > > We can avoid this with yet another new compatible for GPU SMMU something like > "qcom,sc7280-adreno-smmu-500" but since we can handle this easily in the > driver and since the IPs are same, meaning if there was a hardware quirk > required, then we would need to apply to both of them and would this additional > compatible be of any help? > No, I think you're doing the right thing of having them both. I just didn't remember us doing that. > Coming to the part of quirks now, you are right saying both SMMUs will need > to have the same quirks in SC7280 and similar others where both are based on > same IPs but those should probably be *hardware quirks* and if they are > software based like the S2CR quirk depending on the firmware, then it might > not be applicable to both. In case if it is applicable, then as Jordan mentioned, > we can add the same quirks in GPU SMMU implementation. > I do suspect that at some point (probably sooner than later) we'd have to support both inheriting of stream from the bootloader and the Adreno "quirks" in the same instance. But for now this is okay to me. Regards, Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel