Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp1218055pxv; Fri, 9 Jul 2021 22:04:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKLrCEbhPGBpFgFIjydhF8xG74Fyf3hTpay8PhVX3YDBocB9IUVFQbbsNLmCKSBRBhpogR X-Received: by 2002:aa7:c74e:: with SMTP id c14mr23256361eds.40.1625893497522; Fri, 09 Jul 2021 22:04:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625893497; cv=none; d=google.com; s=arc-20160816; b=M4pIExgPj00t5sssArbHxtBO0hhYL11/IxQUJnbEToyuJ4jr0/np8AzoH8g0k0Sowq lWAfCGEvQWiYvkmwUn9L7w766u3HHxWudpjdpqXL/mA635ayxjdAJ4zActab3yWdRi4p eFwQexSNGdN1umWX2B6jkig8dhImH+c+mQpwhMITCE6KhG7ymn+F/K1+c9uMoKaclwDB PaDoPPOp3qnNTgiOV4jBhDmMbk0HpLamX0RCNvQ7ybSbZ3x7fQrVEFOBzgY/vQ5wMBRJ p04MITFuTxQGRwY/HPI0czKn98E8TPYNj8E/ETemnb0gJYmfdgO/QI4eYjkbQ5SPgCwU QfNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=UDGTF4bnijwcKjYKNVG9NXGEhqZ5ES+EVweJisBftjo=; b=xJeh+CUwYtio0jozgCsB6KEs8v+etkxuWZAYPzKULXWtbXD6XeEEeYgCcBF1cTbvkx PQgII4UenOErrHZ64vv1SKVRmMIP1heqThJShJiXp3uq6onWqRf72IqGw4FwTqpyYMXq l3xj3rvFDatUi8fGBQQ1poyASIzhCmt9sYqUkcCXSgNcrDkgcj58c9lDJ9f0HONwWJG3 Wyj0GbgV/XWrVHhN2UspPqXj+fGtmHVI22uW7AiIddMOxqMjKD7zzeW0xEYUp7HvV1o1 3yBu03GCEP4qL9Zodf9esLOEod1for9vALQA4oAQPujfSP21IT0lGhBJaaVCfkO24KrJ cEbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="rb//oRKh"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 24si9640972ejw.232.2021.07.09.22.04.31; Fri, 09 Jul 2021 22:04:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="rb//oRKh"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229912AbhGJE74 (ORCPT + 99 others); Sat, 10 Jul 2021 00:59:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229567AbhGJE7w (ORCPT ); Sat, 10 Jul 2021 00:59:52 -0400 Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A81DFC0613DD for ; Fri, 9 Jul 2021 21:57:06 -0700 (PDT) Received: by mail-oo1-xc2e.google.com with SMTP id p22-20020a4a3c560000b0290256475d95fbso2807203oof.12 for ; Fri, 09 Jul 2021 21:57:06 -0700 (PDT) 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=UDGTF4bnijwcKjYKNVG9NXGEhqZ5ES+EVweJisBftjo=; b=rb//oRKhjIIg8WRDqovlx6mFGLBpj+DC7Hu8AT+FB+MK92XuIgtBA4qqJ11Oo+K5Ab FmwNtZPVEDfz3+dSBucQuFVqvvhF5Xdcgp5+XNu5plRC428resz87Mf9mMfAf+Jzj6lG 5dzuJE35SpsXpWhoOfi5Ko+ENGFNRvzMiZQsEjLDoUcjkyJlcossnmVqE92unXm/ap7I Npi6Pfn18AJqgwbSXaezIzoGDHiM/NOUmxTBWUXtqNfiUyE4Ouex/zTeN57FuKgzjCf6 Yck+fXyxuA4FPgGrjohgUTcUcZjD+eKaZ8bzZaaupimz+te9M1eJnpB/DDNWW5MuAHdz aoUA== 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=UDGTF4bnijwcKjYKNVG9NXGEhqZ5ES+EVweJisBftjo=; b=QXFOAcOY42hNURDJsvFkSTE2Y3jV9j/ZHp+OF6E3RRwfUmy7cbYUeZZqD51/g6p+k/ +4j18zLAqqGbkOP9UWTTZNBCEk9t3ze9TvCYnRdkQk9iefofQZpKziixYwpeBz5nLY5e sjW09VZ8XibjCUFHfB4AtD5WbvwChRmjnCyCuIkiYEBlokASrqG1yVFMiSPdvDOsYQv/ NxWLmYwZj9kzRWsodwRlaSwznoI0hid+9atXpY64BmiuES07c/Y5D5+XPj9cdcIWS7VX 9ZZdehyt2Z1uA1XkeLY2pv78ZeOQ+qwvHVnnODUqJc6/IP4scqCm3rhs+QZyeEli9CHl 2LlQ== X-Gm-Message-State: AOAM532BSpe2g2F+16pWyjx3WCnyemyQyWN330keJLg8ZRLWxJ+3TeLK XXsH+irlsYWsIN5wWU3+/Z/JjQ== X-Received: by 2002:a4a:8749:: with SMTP id a9mr29155288ooi.71.1625893025163; Fri, 09 Jul 2021 21:57:05 -0700 (PDT) Received: from yoga (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id t15sm1718639oiw.16.2021.07.09.21.57.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jul 2021 21:57:04 -0700 (PDT) Date: Fri, 9 Jul 2021 23:57:01 -0500 From: Bjorn Andersson To: Thara Gopinath Cc: agross@kernel.org, rui.zhang@intel.com, daniel.lezcano@linaro.org, viresh.kumar@linaro.org, rjw@rjwysocki.net, robh+dt@kernel.org, tdas@codeaurora.org, mka@chromium.org, linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [Patch v3 3/6] cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support Message-ID: References: <20210708120656.663851-1-thara.gopinath@linaro.org> <20210708120656.663851-4-thara.gopinath@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210708120656.663851-4-thara.gopinath@linaro.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 08 Jul 07:06 CDT 2021, Thara Gopinath wrote: > Add interrupt support to notify the kernel of h/w initiated frequency > throttling by LMh. Convey this to scheduler via thermal presssure > interface. > > Signed-off-by: Thara Gopinath > --- > > v2->v3: > - Cosmetic fixes from review comments on the list. > - Moved all LMh initializations to qcom_cpufreq_hw_lmh_init. > - Added freeing of LMh interrupt and cancelling the polling worker to > qcom_cpufreq_hw_cpu_exit as per Viresh's suggestion. > - LMh interrupts are now tied to cpu dev and not cpufreq dev. This will be > useful for further generation of SoCs where the same interrupt signals > multiple cpu clusters. > > v1->v2: > - Introduced qcom_cpufreq_hw_lmh_init to consolidate LMh related initializations > as per Viresh's review comment. > - Moved the piece of code restarting polling/re-enabling LMh interrupt to > qcom_lmh_dcvs_notify therby simplifying isr and timer callback as per Viresh's > suggestion. > - Droped cpus from qcom_cpufreq_data and instead using cpus from cpufreq_policy in > qcom_lmh_dcvs_notify as per Viresh's review comment. > - Dropped dt property qcom,support-lmh as per Bjorn's suggestion. > - Other minor/cosmetic fixes > > drivers/cpufreq/qcom-cpufreq-hw.c | 118 ++++++++++++++++++++++++++++++ > 1 file changed, 118 insertions(+) > > diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c > index f86859bf76f1..bb5fc700d913 100644 > --- a/drivers/cpufreq/qcom-cpufreq-hw.c > +++ b/drivers/cpufreq/qcom-cpufreq-hw.c > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -22,10 +23,13 @@ > #define CLK_HW_DIV 2 > #define LUT_TURBO_IND 1 > > +#define HZ_PER_KHZ 1000 > + > struct qcom_cpufreq_soc_data { > u32 reg_enable; > u32 reg_freq_lut; > u32 reg_volt_lut; > + u32 reg_current_vote; > u32 reg_perf_state; > u8 lut_row_size; > }; > @@ -33,7 +37,10 @@ struct qcom_cpufreq_soc_data { > struct qcom_cpufreq_data { > void __iomem *base; > struct resource *res; > + struct delayed_work lmh_dcvs_poll_work; How about dropping "lmh" from this variable name? Perhaps "throttle_work" or something like that? > const struct qcom_cpufreq_soc_data *soc_data; > + struct cpufreq_policy *policy; > + int lmh_dcvs_irq; throttle_irq ? > }; > > static unsigned long cpu_hw_rate, xo_rate; > @@ -251,10 +258,84 @@ static void qcom_get_related_cpus(int index, struct cpumask *m) > } > } > > +static inline unsigned long qcom_lmh_vote_to_freq(u32 val) > +{ > + return (val & 0x3FF) * 19200; > +} > + > +static void qcom_lmh_dcvs_notify(struct qcom_cpufreq_data *data) > +{ > + struct cpufreq_policy *policy = data->policy; > + struct dev_pm_opp *opp; > + struct device *dev; > + unsigned long max_capacity, capacity, freq_hz, throttled_freq; > + unsigned int val, freq; > + > + /* > + * Get the h/w throttled frequency, normalize it using the > + * registered opp table and use it to calculate thermal pressure. > + */ > + val = readl_relaxed(data->base + data->soc_data->reg_current_vote); I would find it cleaner to move the readl() into the helper function, as you don't care about the register value, only the resulting frequency. > + freq = qcom_lmh_vote_to_freq(val); > + freq_hz = freq * HZ_PER_KHZ; > + > + dev = get_cpu_device(cpumask_first(policy->cpus)); > + opp = dev_pm_opp_find_freq_floor(dev, &freq_hz); > + if (IS_ERR(opp) && PTR_ERR(opp) == -ERANGE) > + opp = dev_pm_opp_find_freq_ceil(dev, &freq_hz); > + > + throttled_freq = freq_hz / HZ_PER_KHZ; > + > + /* Update thermal pressure */ > + > + max_capacity = arch_scale_cpu_capacity(cpumask_first(policy->cpus)); > + capacity = throttled_freq * max_capacity; > + capacity /= policy->cpuinfo.max_freq; Perhaps, to avoid overflows if this is ever used on a 32-bit platform use: mult_frac(max_capacity, throttled_freq, policy->cpuinfo.max_freq) > + > + /* Don't pass boost capacity to scheduler */ > + if (capacity > max_capacity) > + capacity = max_capacity; > + > + arch_set_thermal_pressure(policy->cpus, max_capacity - capacity); > + > + /* > + * If h/w throttled frequency is higher than what cpufreq has requested for, stop > + * polling and switch back to interrupt mechanism > + */ > + > + if (throttled_freq >= qcom_cpufreq_hw_get(cpumask_first(policy->cpus))) > + /* Clear the existing interrupts and enable it back */ > + enable_irq(data->lmh_dcvs_irq); > + else > + mod_delayed_work(system_highpri_wq, &data->lmh_dcvs_poll_work, > + msecs_to_jiffies(10)); > +} > + > +static void qcom_lmh_dcvs_poll(struct work_struct *work) > +{ > + struct qcom_cpufreq_data *data; > + > + data = container_of(work, struct qcom_cpufreq_data, lmh_dcvs_poll_work.work); > + > + qcom_lmh_dcvs_notify(data); > +} > + > +static irqreturn_t qcom_lmh_dcvs_handle_irq(int irq, void *data) > +{ > + struct qcom_cpufreq_data *c_data = data; > + > + /* Disable interrupt and enable polling */ > + disable_irq_nosync(c_data->lmh_dcvs_irq); > + qcom_lmh_dcvs_notify(c_data); > + > + return 0; > +} > + > static const struct qcom_cpufreq_soc_data qcom_soc_data = { > .reg_enable = 0x0, > .reg_freq_lut = 0x110, > .reg_volt_lut = 0x114, > + .reg_current_vote = 0x704, > .reg_perf_state = 0x920, > .lut_row_size = 32, > }; > @@ -274,6 +355,35 @@ static const struct of_device_id qcom_cpufreq_hw_match[] = { > }; > MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match); > > +static int qcom_cpufreq_hw_lmh_init(struct cpufreq_policy *policy, int index) > +{ > + struct qcom_cpufreq_data *data = policy->driver_data; > + struct platform_device *pdev = cpufreq_get_driver_data(); > + struct device *cpu_dev = get_cpu_device(policy->cpu); > + char irq_name[15]; > + int ret; > + > + /* > + * Look for LMh interrupt. If no interrupt line is specified / > + * if there is an error, allow cpufreq to be enabled as usual. > + */ > + data->lmh_dcvs_irq = platform_get_irq(pdev, index); > + if (data->lmh_dcvs_irq <= 0) > + return data->lmh_dcvs_irq == -EPROBE_DEFER ? -EPROBE_DEFER : 0; > + > + snprintf(irq_name, sizeof(irq_name), "dcvsh-irq-%u", policy->cpu); > + ret = devm_request_irq(cpu_dev, data->lmh_dcvs_irq, qcom_lmh_dcvs_handle_irq, > + 0, irq_name, data); > + if (ret) { > + dev_err(&pdev->dev, "Error %d registering irq %x\n", ret, data->lmh_dcvs_irq); The irq number here won't have any meaning, and %x wouldn't be suitable. How about ..."Error registering %s: %d\n", irq_name, ret); ? > + return 0; This sounds like a problem, wouldn't it be suitable to treat it as a problem? > + } > + data->policy = policy; Afaict, no one is going to access data->policy unless devm_request_irq() succeeds and if it does and the interrupt fires immediately it would be too late to set it here. So better move it earlier. > + INIT_DEFERRABLE_WORK(&data->lmh_dcvs_poll_work, qcom_lmh_dcvs_poll); What if the interrupt fires before you initialize the work? Better move this higher up. > + > + return 0; > +} > + > static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy) > { > struct platform_device *pdev = cpufreq_get_driver_data(); > @@ -370,6 +480,10 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy) > dev_warn(cpu_dev, "failed to enable boost: %d\n", ret); > } > > + ret = qcom_cpufreq_hw_lmh_init(policy, index); > + if (ret) > + goto error; > + > return 0; > error: > kfree(data); > @@ -389,6 +503,10 @@ static int qcom_cpufreq_hw_cpu_exit(struct cpufreq_policy *policy) > > dev_pm_opp_remove_all_dynamic(cpu_dev); > dev_pm_opp_of_cpumask_remove_table(policy->related_cpus); > + if (data->lmh_dcvs_irq > 0) { > + devm_free_irq(cpu_dev, data->lmh_dcvs_irq, data); As init/exit are called multiple times you should avoid the devm variants. Regards, Bjorn > + cancel_delayed_work_sync(&data->lmh_dcvs_poll_work); > + } > kfree(policy->freq_table); > kfree(data); > iounmap(base); > -- > 2.25.1 >