Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp2190053rdd; Fri, 12 Jan 2024 02:02:05 -0800 (PST) X-Google-Smtp-Source: AGHT+IFmX8O5tVDr4tSBS7+IINJL+mzjnSGBC0DGQnNKIV2JYbPxO26fgSuyBn/hvy2Rc5hWxUGe X-Received: by 2002:a17:906:7944:b0:a2c:2185:6dfe with SMTP id l4-20020a170906794400b00a2c21856dfemr635241ejo.105.1705053725340; Fri, 12 Jan 2024 02:02:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705053725; cv=none; d=google.com; s=arc-20160816; b=lP0PeanzyISoClOYKOkXYXTJK/ICGtgPjxFtnX3n88H6pzuj8aBkwVH5KrlO6U79F4 OC/lftbOTory9gNx/4qEKjN9JMrtzqKuBhjCbr78ipd0YOOtZBoNcnSpcd0lb/mezrto oOj/i5WjBfXKppej0wcnFNeC+yKr6/TaTjL+omVKDiCP8BxW5Jk1wBISV1jMVQoYAcSJ FmI5n3KKR+3o4aPa97572Yhq+3fL0z6gaQ2rIU5eUURX87y6ABeYFiHcOTEkCDMLv204 UovP3lUt/ii1CL4+jFSUZ3xJjhw70CVja3WD+2T9BSd6P9rvqUXwk5hMPQj4ppFORW3r bmyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=n6BjmcfWjZQ9/+4cG+gO0wA5RcUkVwPj/srDhWTeVkw=; fh=HbmvjXY04xEmQt7Xkv0lC0bqgOZslMH4vgaejuIgDSo=; b=PxmqviAn0uTtKjAPC6/IhfIljYBqo0BiGfkbNKIp+ZeKERP8Nn+PjbIamtgdo8tnE/ ertmby2oabXy/lBn2fgHtryVauuL8AwWyWkOmZkbph6CZPhPYiUL+f5xjKReuhdBGyHQ 4q6VAmnNdxZnlTBH1BB1dLw4s2YYFcVbB6b+dnub+dpaJBoRIyks5WdmEOnteJ12cyiQ ExQI6KqEVxEp178lVek/fw0UUf0q5pyjSJg4QxgDzlru95mm1n9g4qjhL1Vw0DohEuRb ImdAdJ+IdgOoHIPzYVWQUG4F4st21lkok0tJVJ/DJGH5V3FnRWteOXuudnE26bYkBw1p lIag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=V5GRtRoC; spf=pass (google.com: domain of linux-kernel+bounces-24537-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-24537-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id j13-20020a170906830d00b00a27b5d97c66si1271887ejx.47.2024.01.12.02.02.05 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jan 2024 02:02:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-24537-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=V5GRtRoC; spf=pass (google.com: domain of linux-kernel+bounces-24537-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-24537-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id CD8F71F27631 for ; Fri, 12 Jan 2024 10:01:37 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8CAFD57865; Fri, 12 Jan 2024 10:01:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="V5GRtRoC" Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4C0557328 for ; Fri, 12 Jan 2024 10:01:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-50e7d6565b5so7212124e87.0 for ; Fri, 12 Jan 2024 02:01:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1705053683; x=1705658483; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=n6BjmcfWjZQ9/+4cG+gO0wA5RcUkVwPj/srDhWTeVkw=; b=V5GRtRoCbV0UdeRaGPrx1hssWP2IkGtm9X1OiS3/2BfzJMH6EhsC5hhpdx/VDg7zVq enTu9Xzt7ckmL2JByPXWkGtbDufp0k8zlFi6iV6CAJs5q2CTACYMD98AmpwhMOxHrq7Q NMB2SPKznzpwer5TpjobKdso3u5JjHw6CuIyAROv40j4/LVhgBp9f5gwvN6mcep8HIsN tQeWdNwzuK+NpP9baoVTNp5ZkcCRz73ZrARumsZk0vyc0AqNqJFqolxGCfqQ7U9skz5u 9C+0eskPZ273MO57LY3VRO3XLJpeq5MO9FopY/rB4OMEDDTrmwiACcgtIuHQnu+6CSoE 7kYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705053683; x=1705658483; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=n6BjmcfWjZQ9/+4cG+gO0wA5RcUkVwPj/srDhWTeVkw=; b=rI6LQkgK/MCpE0WH6Ip4zo9+FIlf79sSSbVrBph4LgGxHiGNRchip/YAMKbAF8hIq5 gUhv9mM9+Up+UDABgTLLBfj5x856Wk34U+FOJA0bH6fKUCa8aU1XK9KRYT4j0CtT8meQ jEyDIpQCJ+rDhbd7D2tRY5WOs5Vjy/uF8t5KaaLaC9vznlyEaz7iz1WwoTLxxUMz1Yq7 jw6jYRdGE2585QzwUWGbZuj/FXTZxKx37SXryhGn9VmFJYq/s/4+axpyI7lf+yV+zBR1 0Kj851EXzKTfVpJfzZ0beFoazDVZBYlSTqN/u+mqWOljJPqr+Pfneappq5PzvLiZ3Ceo SmVQ== X-Gm-Message-State: AOJu0Ywxtl4oLwoMFTqGRLs135UQLNKwyQnDaJMSDteA3deKxeSr62yn 7n1FSXeXXP8fWsMXDsH+s9Rbt5HLTjVIHg== X-Received: by 2002:a2e:8007:0:b0:2cd:63e4:75ff with SMTP id j7-20020a2e8007000000b002cd63e475ffmr517106ljg.35.1705053682887; Fri, 12 Jan 2024 02:01:22 -0800 (PST) Received: from [172.30.204.205] (UNUSED.212-182-62-129.lubman.net.pl. [212.182.62.129]) by smtp.gmail.com with ESMTPSA id x7-20020a2e9c87000000b002cd0435c50bsm407024lji.72.2024.01.12.02.01.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jan 2024 02:01:22 -0800 (PST) Message-ID: Date: Fri, 12 Jan 2024 11:01:21 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 3/5] iommu/arm-smmu: introduction of ACTLR for custom prefetcher settings To: Bibek Kumar Patro , Pavan Kondeti Cc: will@kernel.org, robin.murphy@arm.com, joro@8bytes.org, dmitry.baryshkov@linaro.org, jsnitsel@redhat.com, quic_bjorande@quicinc.com, mani@kernel.org, quic_eberman@quicinc.com, robdclark@chromium.org, u.kleine-koenig@pengutronix.de, robh@kernel.org, vladimir.oltean@nxp.com, quic_molvera@quicinc.com, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org References: <20240109114220.30243-1-quic_bibekkum@quicinc.com> <20240109114220.30243-4-quic_bibekkum@quicinc.com> <2ad70157-27d1-41df-8866-c226af690cf6@quicinc.com> <4a595815-7fcc-47e2-b22c-dac349af6d79@quicinc.com> <492aeca3-a4df-47a3-9c77-02ea4235d736@linaro.org> <1a1f9b11-5a6d-41f7-8bcd-533a61a27a65@quicinc.com> Content-Language: en-US From: Konrad Dybcio In-Reply-To: <1a1f9b11-5a6d-41f7-8bcd-533a61a27a65@quicinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/11/24 19:09, Bibek Kumar Patro wrote: > > > On 1/10/2024 11:26 PM, Konrad Dybcio wrote: >> >> >> On 1/10/24 13:55, Bibek Kumar Patro wrote: >>> >>> >>> On 1/10/2024 4:46 PM, Bibek Kumar Patro wrote: >>>> >>>> >>>> On 1/10/2024 9:36 AM, Pavan Kondeti wrote: >>> >>> [...] >>> >>>>>> @@ -274,6 +321,21 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = { >>>>>>   static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain, >>>>>>           struct io_pgtable_cfg *pgtbl_cfg, struct device *dev) >>>>>>   { >>>>>> +    struct arm_smmu_device *smmu = smmu_domain->smmu; >>>>>> +    struct qcom_smmu *qsmmu = to_qcom_smmu(smmu); >>>>>> +    const struct actlr_variant *actlrvar; >>>>>> +    int cbndx = smmu_domain->cfg.cbndx; >>>>>> + >>>>>> +    if (qsmmu->data->actlrvar) { >>>>>> +        actlrvar = qsmmu->data->actlrvar; >>>>>> +        for (; actlrvar->io_start; actlrvar++) { >>>>>> +            if (actlrvar->io_start == smmu->ioaddr) { >>>>>> +                qcom_smmu_set_actlr(dev, smmu, cbndx, actlrvar->actlrcfg); >>>>>> +                break; >>>>>> +            } >>>>>> +        } >>>>>> +    } >>>>>> + >>>>> >>>>> This block and the one in qcom_adreno_smmu_init_context() are exactly >>>>> the same. Possible to do some refactoring? >>>>> >>>> >>>> I will check if this repeated blocks can be accomodated this into qcom_smmu_set_actlr function if that would be fine. >>>> >>> >>> Also adding to this, this might increase the number of indentation inside qcom_smmu_set_actlr as well, to around 5. So wouldn't this >>> be an issue? >> >> By the way, we can refactor this: >> >> if (qsmmu->data->actlrvar) { >>      actlrvar = qsmmu->data->actlrvar; >>      for (; actlrvar->io_start; actlrvar++) { >>          if (actlrvar->io_start == smmu->ioaddr) { >>              qcom_smmu_set_actlr(dev, smmu, cbndx, actlrvar->actlrcfg); >>              break; >>          } >>      } >> } >> >> into >> >> // add const u8 num_actlrcfgs to struct actrl_variant to >> // save on sentinel space: >> //   sizeof(u8) < sizeof(ptr) + sizeof(resource_size_t) >> > > Git it, Would it be better to add this in struct qcom_smmu_match_data ? Yes, right. > Posted a sample below. > >> >> [declarations] >> const struct actlr_variant *actlrvar = qsmmu->data->actlrvar; >> int i; >> >> [rest of the functions] >> >> if (!actlrvar) >>      return 0; >>  > for (i = 0; i < actrlvar->num_actrlcfgs; i++) { >>      if (actlrvar[i].io_start == smmu->ioaddr) { >>          qcom_smmu_set_actlr(dev, smmu, cbndx, actlrvar->actlrcfg); >>          break; >>      } >> } >>  > Saving both on .TEXT size and indentation levels :) >> > Thanks for this suggestion Konrad, will try to implement this, as it would reduce the indent levels to good extent. > Would something like this be okay? > > static int qcom_smmu_init_context(struct arm_smmu_domain *smmu_domain, >      struct qcom_smmu *qsmmu = to_qcom_smmu(smmu); >      const struct actlr_variant *actlrvar; >      int cbndx = smmu_domain->cfg.cbndx; > +    int i; > > +    actlrvar = qsmmu->data->actlrvar; > + > +    if (!actlrvar) > +        goto end; > + > +    for (i = 0; i < qsmmu->data->num_smmu ; i++) { > +        if (actlrvar[i].io_start == smmu->ioaddr) { > +            qcom_smmu_set_actlr(dev, smmu, cbndx, > +                        actlrvar[i].actlrcfg); > +            break; >          } >      } > > +end: >      smmu_domain->cfg.flush_walk_prefer_tlbiasid = true; If you move this assignment before the actlrvar checking (there's no dependency between them), you will get rid of the goto. I also noticed that qcom_smmu_match_data.actlrvar could likely be const struct actlr_variant * const (const pointer to a const resource), similarly for actlr_variant.actlrcfg Konrad