[{"id":1760468,"web_url":"http://patchwork.ozlabs.org/comment/1760468/","msgid":"<20170830202650.mdlxy2c3uwuq5vde@kozik-lap>","list_archive_url":null,"date":"2017-08-30T20:26:50","subject":"Re: [PATCH 2/4] arm: dts: exynos: add exynos5420 cpu\n\tcapacity-dmips-mhz information","submitter":{"id":68952,"url":"http://patchwork.ozlabs.org/api/people/68952/","name":"Krzysztof Kozlowski","email":"krzk@kernel.org"},"content":"On Wed, Aug 30, 2017 at 03:41:18PM +0100, Dietmar Eggemann wrote:\n> The following 'capacity-dmips-mhz' dt property values are used:\n> \n> Cortex-A15: 1024, Cortex-A7: 539\n> \n> They have been derived from the cpu_efficiency values:\n> \n> Cortex-A15: 3891, Cortex-A7: 2048\n> \n> by scaling them so that the Cortex-A15s (big cores) use 1024.\n> \n> The cpu_efficiency values were originally derived from the \"Big.LITTLE\n> Processing with ARM Cortex™-A15 & Cortex-A7\" white paper\n> (http://www.cl.cam.ac.uk/~rdm34/big.LITTLE.pdf). Table 1 lists 1.9x\n> (3891/2048) as the Cortex-A15 vs Cortex-A7 performance ratio for the\n> Dhrystone benchmark.\n> \n> The following platforms are affected once cpu-invariant accounting\n> support is re-connected to the task scheduler:\n> \n> arndale-octa, peach-pi, peach-pit, smdk5420\n> \n> The patch has been tested on Samsung Chromebook 2 13\" (peach-pi, Exynos\n> 5800).\n> \n> $ cat /sys/devices/system/cpu/cpu*/cpu_capacity\n> 1024\n> 1024\n> 1024\n> 1024\n> 389\n> 389\n> 389\n> 389\n\nI am missing something... shouldn't this be 539? Or is it scaled with\nthe clock-frequency (1 GHz) value?\n\n\nBest regards,\nKrzysztof\n\n\n> \n> The Cortex-A15 vs Cortex-A7 performance ratio is 1024/389 = 2.63.\n> \n> The values derived with the 'cpu_efficiency/clock-frequency dt property'\n> solution are:\n> \n> $ cat /sys/devices/system/cpu/cpu*/cpu_capacity\n> 1535\n> 1535\n> 1535\n> 1535\n> 448\n> 448\n> 448\n> 448\n> \n> The Cortex-A15 vs Cortex-A7 performance ratio is 1535/448 = 3.43.\n> \n> The discrepancy between 2.63 and 3.43 is due to the false assumption\n> when using the 'cpu_efficiency/clock-frequency dt property' solution\n> that the max cpu frequency of the little cpus is 1 GHZ and not 1.3 GHz.\n> The Cortex-A7 cluster runs with a max cpu frequency of 1.3 GHZ whereas\n> the 'clock-frequency' property value is set to 1 GHz.\n> \n> 3.43/1.3 = 2.64\n> \n> $ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq\n> 1800000\n> 1800000\n> 1800000\n> 1800000\n> 1300000 <-- max cpu frequency of the Cortex-A7s (little cores)\n> 1300000\n> 1300000\n> 1300000\n> \n> Running another benchmark (single-threaded sysbench affine to the\n> individual cpus) with performance cpufreq governor on the Samsung\n> Chromebook 2 13\" showed the following numbers:\n> \n> $ for i in `seq 0 7`; do taskset -c $i sysbench --test=cpu\n> --num-threads=1 --max-time=10 run | grep \"total number of events:\";\n> done\n> \n> total number of events: 1083\n> total number of events: 1085\n> total number of events: 1085\n> total number of events: 1085\n> total number of events: 454\n> total number of events: 454\n> total number of events: 454\n> total number of events: 454\n> \n> The Cortex-A15 vs Cortex-A7 performance ratio is 2.39, i.e. very close\n> to the one derived from the Dhrystone based one of the \"Big.LITTLE\n> Processing with ARM Cortex™-A15 & Cortex-A7\" white paper (2.63).\n> \n> We don't aim for exact values for the cpu capacity values. Besides the\n> CPI (Cycles Per Instruction), the instruction mix and whether the system\n> runs cpu-bound or memory-bound has an impact on the cpu capacity values\n> derived from these benchmark results.\n> \n> Cc: Rob Herring \n> Cc: Mark Rutland \n> Cc: Russell King \n> Cc: Kukjin Kim \n> Cc: Krzysztof Kozlowski \n> Signed-off-by: Dietmar Eggemann \n> ---\n> arch/arm/boot/dts/exynos5420-cpus.dtsi | 8 ++++++++\n> 1 file changed, 8 insertions(+)\n> \n> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi\n> index 5c052d7ff554..d7d703aa1699 100644\n> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi\n> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi\n> @@ -36,6 +36,7 @@\n> \t\t\tcooling-min-level = <0>;\n> \t\t\tcooling-max-level = <11>;\n> \t\t\t#cooling-cells = <2>; /* min followed by max */\n> +\t\t\tcapacity-dmips-mhz = <1024>;\n> \t\t};\n> \n> \t\tcpu1: cpu@1 {\n> @@ -48,6 +49,7 @@\n> \t\t\tcooling-min-level = <0>;\n> \t\t\tcooling-max-level = <11>;\n> \t\t\t#cooling-cells = <2>; /* min followed by max */\n> +\t\t\tcapacity-dmips-mhz = <1024>;\n> \t\t};\n> \n> \t\tcpu2: cpu@2 {\n> @@ -60,6 +62,7 @@\n> \t\t\tcooling-min-level = <0>;\n> \t\t\tcooling-max-level = <11>;\n> \t\t\t#cooling-cells = <2>; /* min followed by max */\n> +\t\t\tcapacity-dmips-mhz = <1024>;\n> \t\t};\n> \n> \t\tcpu3: cpu@3 {\n> @@ -72,6 +75,7 @@\n> \t\t\tcooling-min-level = <0>;\n> \t\t\tcooling-max-level = <11>;\n> \t\t\t#cooling-cells = <2>; /* min followed by max */\n> +\t\t\tcapacity-dmips-mhz = <1024>;\n> \t\t};\n> \n> \t\tcpu4: cpu@100 {\n> @@ -85,6 +89,7 @@\n> \t\t\tcooling-min-level = <0>;\n> \t\t\tcooling-max-level = <7>;\n> \t\t\t#cooling-cells = <2>; /* min followed by max */\n> +\t\t\tcapacity-dmips-mhz = <539>;\n> \t\t};\n> \n> \t\tcpu5: cpu@101 {\n> @@ -97,6 +102,7 @@\n> \t\t\tcooling-min-level = <0>;\n> \t\t\tcooling-max-level = <7>;\n> \t\t\t#cooling-cells = <2>; /* min followed by max */\n> +\t\t\tcapacity-dmips-mhz = <539>;\n> \t\t};\n> \n> \t\tcpu6: cpu@102 {\n> @@ -109,6 +115,7 @@\n> \t\t\tcooling-min-level = <0>;\n> \t\t\tcooling-max-level = <7>;\n> \t\t\t#cooling-cells = <2>; /* min followed by max */\n> +\t\t\tcapacity-dmips-mhz = <539>;\n> \t\t};\n> \n> \t\tcpu7: cpu@103 {\n> @@ -121,6 +128,7 @@\n> \t\t\tcooling-min-level = <0>;\n> \t\t\tcooling-max-level = <7>;\n> \t\t\t#cooling-cells = <2>; /* min followed by max */\n> +\t\t\tcapacity-dmips-mhz = <539>;\n> \t\t};\n> \t};\n> };\n> -- \n> 2.11.0\n> \n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xjH9R0C5qz9sPm\n\tfor ;\n\tThu, 31 Aug 2017 06:27:07 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751110AbdH3U1F convert rfc822-to-8bit (ORCPT\n\t);\n\tWed, 30 Aug 2017 16:27:05 -0400","from mail-pg0-f49.google.com ([74.125.83.49]:35591 \"EHLO\n\tmail-pg0-f49.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750890AbdH3U1E (ORCPT\n\t); Wed, 30 Aug 2017 16:27:04 -0400","by mail-pg0-f49.google.com with SMTP id 63so22831854pgc.2;\n\tWed, 30 Aug 2017 13:27:03 -0700 (PDT)","from kozik-lap ([185.13.106.193])\n\tby smtp.googlemail.com with ESMTPSA id\n\ts1sm4492312pfk.21.2017.08.30.13.26.55\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tWed, 30 Aug 2017 13:27:02 -0700 (PDT)"],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to:user-agent;\n\tbh=FHNePBSxmNGza2y+fODRwMhIGHqZyyPRqCygy7ARlQs=;\n\tb=rWTQvCupLHA5wvCiwxDTmkGTCMsubF0EcZkRxP90yf02xbo7eYnY5Lo3CrUATpFgNh\n\typ6VEGE93Ubu6igCQnarZaStQTf83qXor9xEk/6LQOdpf+i58ZQirk0jLkLbDtSiJN1u\n\tBsLfmxdLYu0OCnZtVxivSREEF8cuZXrdGJDoVEdooDLI6nYiMJ2plUpR7HoVfo8yjkv2\n\tTaL7le1SEfpojkDwAFH0wQDv0ybql0xqlC75OeF/YVfJaUOeamQ6R0llVTYQtMvPcpCS\n\tt6XLirb4EERZZojYAAcDBB6/xeuThGmI3mDf/pmmpShFUhGsPGu574+bb3G6IcU6CggN\n\th5Yw==","X-Gm-Message-State":"AHYfb5hd5NrsO7JirtzN/qHdPHMrL7dqKRsJTvH9CoVE8xtineET+8sK\n\tV/lgMQncJ6jvWg==","X-Received":"by 10.84.224.10 with SMTP id r10mr3424058plj.149.1504124823402; \n\tWed, 30 Aug 2017 13:27:03 -0700 (PDT)","Date":"Wed, 30 Aug 2017 22:26:50 +0200","From":"Krzysztof Kozlowski ","To":"Dietmar Eggemann ","Cc":"linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,\n\tlinux-renesas-soc@vger.kernel.org, Russell King , \n\tRob Herring , Mark Rutland ,\n\tKukjin Kim ,\n\tVincent Guittot ,\n\tJuri Lelli ","Subject":"Re: [PATCH 2/4] arm: dts: exynos: add exynos5420 cpu\n\tcapacity-dmips-mhz information","Message-ID":"<20170830202650.mdlxy2c3uwuq5vde@kozik-lap>","References":"<20170830144120.9312-1-dietmar.eggemann@arm.com>\n\t<20170830144120.9312-3-dietmar.eggemann@arm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8BIT","In-Reply-To":"<20170830144120.9312-3-dietmar.eggemann@arm.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1760820,"web_url":"http://patchwork.ozlabs.org/comment/1760820/","msgid":"<94c1d6c6-655a-2a63-1f01-06ac45990388@arm.com>","list_archive_url":null,"date":"2017-08-31T10:36:07","subject":"Re: [PATCH 2/4] arm: dts: exynos: add exynos5420 cpu\n\tcapacity-dmips-mhz information","submitter":{"id":64545,"url":"http://patchwork.ozlabs.org/api/people/64545/","name":"Dietmar Eggemann","email":"dietmar.eggemann@arm.com"},"content":"On 30/08/17 21:26, Krzysztof Kozlowski wrote:\n> On Wed, Aug 30, 2017 at 03:41:18PM +0100, Dietmar Eggemann wrote:\n>> The following 'capacity-dmips-mhz' dt property values are used:\n>>\n>> Cortex-A15: 1024, Cortex-A7: 539\n>>\n>> They have been derived from the cpu_efficiency values:\n>>\n>> Cortex-A15: 3891, Cortex-A7: 2048\n>>\n>> by scaling them so that the Cortex-A15s (big cores) use 1024.\n>>\n>> The cpu_efficiency values were originally derived from the \"Big.LITTLE\n>> Processing with ARM Cortex™-A15 & Cortex-A7\" white paper\n>> (http://www.cl.cam.ac.uk/~rdm34/big.LITTLE.pdf). Table 1 lists 1.9x\n>> (3891/2048) as the Cortex-A15 vs Cortex-A7 performance ratio for the\n>> Dhrystone benchmark.\n>>\n>> The following platforms are affected once cpu-invariant accounting\n>> support is re-connected to the task scheduler:\n>>\n>> arndale-octa, peach-pi, peach-pit, smdk5420\n>>\n>> The patch has been tested on Samsung Chromebook 2 13\" (peach-pi, Exynos\n>> 5800).\n>>\n>> $ cat /sys/devices/system/cpu/cpu*/cpu_capacity\n>> 1024\n>> 1024\n>> 1024\n>> 1024\n>> 389\n>> 389\n>> 389\n>> 389\n> \n> I am missing something... shouldn't this be 539? Or is it scaled with\n> the clock-frequency (1 GHz) value?\n\nYeah, the capacity-dmips-mhz dt value of 539 for the little cpus is\nscaled by 1.3/1.8 (max cpu capacity/ system wide max cpu capacity):\n\n539 * 1.3/1.8 = 389\n\nThis max cpu capacity scaling is part of both solutions, the 'cpu\ncapacity-dmips-mhz' and the 'cpu_efficiency/clock-frequency dt property'\none.\n\nThe (original*) cpu capacity on a heterogeneous platform expresses uArch\nand max cpu frequency differences between the (logical) cpus of the\nsystem.\n\n* not further reduced by rt and/or irq pressure.\n\n[...]\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xjf1B1ltjz9t1t\n\tfor ;\n\tThu, 31 Aug 2017 20:36:14 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750757AbdHaKgM (ORCPT\n\t);\n\tThu, 31 Aug 2017 06:36:12 -0400","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:54034 \"EHLO\n\tfoss.arm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750790AbdHaKgL (ORCPT );\n\tThu, 31 Aug 2017 06:36:11 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D970880D;\n\tThu, 31 Aug 2017 03:36:10 -0700 (PDT)","from [10.1.210.41] (e107985-lin.cambridge.arm.com [10.1.210.41])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\tCA43B3F58F; Thu, 31 Aug 2017 03:36:08 -0700 (PDT)"],"Subject":"Re: [PATCH 2/4] arm: dts: exynos: add exynos5420 cpu\n\tcapacity-dmips-mhz information","To":"Krzysztof Kozlowski ","Cc":"linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,\n\tlinux-renesas-soc@vger.kernel.org, Russell King , \n\tRob Herring , Mark Rutland ,\n\tKukjin Kim ,\n\tVincent Guittot ,\n\tJuri Lelli ","References":"<20170830144120.9312-1-dietmar.eggemann@arm.com>\n\t<20170830144120.9312-3-dietmar.eggemann@arm.com>\n\t<20170830202650.mdlxy2c3uwuq5vde@kozik-lap>","From":"Dietmar Eggemann ","Message-ID":"<94c1d6c6-655a-2a63-1f01-06ac45990388@arm.com>","Date":"Thu, 31 Aug 2017 11:36:07 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170830202650.mdlxy2c3uwuq5vde@kozik-lap>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-GB","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762327,"web_url":"http://patchwork.ozlabs.org/comment/1762327/","msgid":"<20170903195614.iwe7v6g3xsg7p6nf@kozik-lap>","list_archive_url":null,"date":"2017-09-03T19:56:14","subject":"Re: [PATCH 2/4] arm: dts: exynos: add exynos5420 cpu\n\tcapacity-dmips-mhz information","submitter":{"id":68952,"url":"http://patchwork.ozlabs.org/api/people/68952/","name":"Krzysztof Kozlowski","email":"krzk@kernel.org"},"content":"On Thu, Aug 31, 2017 at 11:36:07AM +0100, Dietmar Eggemann wrote:\n> On 30/08/17 21:26, Krzysztof Kozlowski wrote:\n> > On Wed, Aug 30, 2017 at 03:41:18PM +0100, Dietmar Eggemann wrote:\n> >> The following 'capacity-dmips-mhz' dt property values are used:\n> >>\n> >> Cortex-A15: 1024, Cortex-A7: 539\n> >>\n> >> They have been derived from the cpu_efficiency values:\n> >>\n> >> Cortex-A15: 3891, Cortex-A7: 2048\n> >>\n> >> by scaling them so that the Cortex-A15s (big cores) use 1024.\n> >>\n> >> The cpu_efficiency values were originally derived from the \"Big.LITTLE\n> >> Processing with ARM Cortex™-A15 & Cortex-A7\" white paper\n> >> (http://www.cl.cam.ac.uk/~rdm34/big.LITTLE.pdf). Table 1 lists 1.9x\n> >> (3891/2048) as the Cortex-A15 vs Cortex-A7 performance ratio for the\n> >> Dhrystone benchmark.\n> >>\n> >> The following platforms are affected once cpu-invariant accounting\n> >> support is re-connected to the task scheduler:\n> >>\n> >> arndale-octa, peach-pi, peach-pit, smdk5420\n> >>\n> >> The patch has been tested on Samsung Chromebook 2 13\" (peach-pi, Exynos\n> >> 5800).\n> >>\n> >> $ cat /sys/devices/system/cpu/cpu*/cpu_capacity\n> >> 1024\n> >> 1024\n> >> 1024\n> >> 1024\n> >> 389\n> >> 389\n> >> 389\n> >> 389\n> > \n> > I am missing something... shouldn't this be 539? Or is it scaled with\n> > the clock-frequency (1 GHz) value?\n> \n> Yeah, the capacity-dmips-mhz dt value of 539 for the little cpus is\n> scaled by 1.3/1.8 (max cpu capacity/ system wide max cpu capacity):\n> \n> 539 * 1.3/1.8 = 389\n> \n> This max cpu capacity scaling is part of both solutions, the 'cpu\n> capacity-dmips-mhz' and the 'cpu_efficiency/clock-frequency dt property'\n> one.\n> \n> The (original*) cpu capacity on a heterogeneous platform expresses uArch\n> and max cpu frequency differences between the (logical) cpus of the\n> system.\n> \n> * not further reduced by rt and/or irq pressure.\n> \n> [...]\n\nThanks for explanation, looks fine for me. I'll take it after merge\nwindow.\n\nBest regards,\nKrzysztof\n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xlkJC5LWKz9sRY\n\tfor ;\n\tMon, 4 Sep 2017 05:56:27 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751592AbdICT4X convert rfc822-to-8bit (ORCPT\n\t);\n\tSun, 3 Sep 2017 15:56:23 -0400","from mail-pg0-f53.google.com ([74.125.83.53]:36532 \"EHLO\n\tmail-pg0-f53.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751569AbdICT4W (ORCPT\n\t); Sun, 3 Sep 2017 15:56:22 -0400","by mail-pg0-f53.google.com with SMTP id r133so13358850pgr.3;\n\tSun, 03 Sep 2017 12:56:21 -0700 (PDT)","from kozik-lap ([185.13.106.193])\n\tby smtp.googlemail.com with ESMTPSA id\n\ti187sm8390388pfe.67.2017.09.03.12.56.16\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tSun, 03 Sep 2017 12:56:20 -0700 (PDT)"],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to:user-agent;\n\tbh=rS/eq7RFBHCZ6yzjwaVP4OWq3t5A9EQz8a0kKyondmY=;\n\tb=AkNKa+E3uWfNkNPAAa8XMNRx+IY4ip5BQqA5sJ3XNCPZB1ZBRPvdv+4qSHxRuen/j6\n\tyG4L2lN9n4W7pA7TOMMnlVTGgYG3Tz9PtPq8VGhc+9HLB1uXg+vJwFGY3rqPgEvBKlni\n\t0hRAxS2UHFq2QAdqNHFjstXDMyiIJam94ZPsd2S/5sOscC5Xrc+wmF2qIjQAzYGWmcWY\n\tiKf6kj9zjKhYKc8ulIvsIA2jd59mN80zvDjDG4SLfrZQeTR5qu7Oo4Ud+a4UcplhoaHz\n\t+HXW8x6WncP7CehhpMYnRidWVHFoYZjErKx2ZGrTdM8oPW8LJCCzimHzbmuKFIitk8Ix\n\tiqIQ==","X-Gm-Message-State":"AHPjjUi6jMolb8s9DWhEpjQSPsbeE83s5NrhkDIg5FLdFWTaR1ZHqfWt\n\tJNaP0oOQWsN6QXZTVvg=","X-Google-Smtp-Source":"ADKCNb6jQDm0CBhut0rc5z6wGgCXou3mP+D/Ptc7ErdCXObRSOn3bM67U2YUOBg0dyxpRZDa/YKcKg==","X-Received":"by 10.98.102.77 with SMTP id a74mr9163355pfc.293.1504468581564; \n\tSun, 03 Sep 2017 12:56:21 -0700 (PDT)","Date":"Sun, 3 Sep 2017 21:56:14 +0200","From":"Krzysztof Kozlowski ","To":"Dietmar Eggemann ","Cc":"linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,\n\tlinux-renesas-soc@vger.kernel.org, Russell King , \n\tRob Herring , Mark Rutland ,\n\tKukjin Kim ,\n\tVincent Guittot ,\n\tJuri Lelli ","Subject":"Re: [PATCH 2/4] arm: dts: exynos: add exynos5420 cpu\n\tcapacity-dmips-mhz information","Message-ID":"<20170903195614.iwe7v6g3xsg7p6nf@kozik-lap>","References":"<20170830144120.9312-1-dietmar.eggemann@arm.com>\n\t<20170830144120.9312-3-dietmar.eggemann@arm.com>\n\t<20170830202650.mdlxy2c3uwuq5vde@kozik-lap>\n\t<94c1d6c6-655a-2a63-1f01-06ac45990388@arm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8BIT","In-Reply-To":"<94c1d6c6-655a-2a63-1f01-06ac45990388@arm.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762488,"web_url":"http://patchwork.ozlabs.org/comment/1762488/","msgid":"","list_archive_url":null,"date":"2017-09-04T07:49:11","subject":"Re: [PATCH 1/4] arm: topology: remove cpu_efficiency","submitter":{"id":22608,"url":"http://patchwork.ozlabs.org/api/people/22608/","name":"Vincent Guittot","email":"vincent.guittot@linaro.org"},"content":"Hi Dietmar,\n\nRemoving cpu effificiency table looks good to me. Nevertheless, i have\nsome comments below for this patch.\n\nOn 30 August 2017 at 16:41, Dietmar Eggemann wrote:\n> Remove the 'cpu_efficiency/clock-frequency dt property' based solution\n> to set cpu capacity which was only working for Cortex-A15/A7 arm\n> big.LITTLE systems.\n>\n> I.e. the 'capacity-dmips-mhz' based solution is now the only one. It is\n> shared between arm and arm64 and works for every big.LITTLE system no\n> matter which core types it consists of.\n>\n> Cc: Russell King \n> Cc: Vincent Guittot \n> Cc: Juri Lelli \n> Signed-off-by: Dietmar Eggemann \n> ---\n> arch/arm/kernel/topology.c | 113 ++-------------------------------------------\n> 1 file changed, 3 insertions(+), 110 deletions(-)\n>\n> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c\n> index bf949a763dbe..04ccfdd94213 100644\n> --- a/arch/arm/kernel/topology.c\n> +++ b/arch/arm/kernel/topology.c\n> @@ -47,52 +47,10 @@\n> */\n>\n> #ifdef CONFIG_OF\n> -struct cpu_efficiency {\n> - const char *compatible;\n> - unsigned long efficiency;\n> -};\n> -\n> -/*\n> - * Table of relative efficiency of each processors\n> - * The efficiency value must fit in 20bit and the final\n> - * cpu_scale value must be in the range\n> - * 0 < cpu_scale < 3*SCHED_CAPACITY_SCALE/2\n> - * in order to return at most 1 when DIV_ROUND_CLOSEST\n> - * is used to compute the capacity of a CPU.\n> - * Processors that are not defined in the table,\n> - * use the default SCHED_CAPACITY_SCALE value for cpu_scale.\n> - */\n> -static const struct cpu_efficiency table_efficiency[] = {\n> - {\"arm,cortex-a15\", 3891},\n> - {\"arm,cortex-a7\", 2048},\n> - {NULL, },\n> -};\n> -\n> -static unsigned long *__cpu_capacity;\n> -#define cpu_capacity(cpu) __cpu_capacity[cpu]\n> -\n> -static unsigned long middle_capacity = 1;\n> -static bool cap_from_dt = true;\n> -\n> -/*\n> - * Iterate all CPUs' descriptor in DT and compute the efficiency\n> - * (as per table_efficiency). Also calculate a middle efficiency\n> - * as close as possible to (max{eff_i} - min{eff_i}) / 2\n> - * This is later used to scale the cpu_capacity field such that an\n> - * 'average' CPU is of middle capacity. Also see the comments near\n> - * table_efficiency[] and update_cpu_capacity().\n> - */\n> static void __init parse_dt_topology(void)\n> {\n> - const struct cpu_efficiency *cpu_eff;\n> - struct device_node *cn = NULL;\n> - unsigned long min_capacity = ULONG_MAX;\n> - unsigned long max_capacity = 0;\n> - unsigned long capacity = 0;\n> - int cpu = 0;\n> -\n> - __cpu_capacity = kcalloc(nr_cpu_ids, sizeof(*__cpu_capacity),\n> - GFP_NOWAIT);\n> + struct device_node *cn;\n> + int cpu;\n>\n> cn = of_find_node_by_path(\"/cpus\");\n> if (!cn) {\n> @@ -101,9 +59,6 @@ static void __init parse_dt_topology(void)\n> }\n>\n> for_each_possible_cpu(cpu) {\n> - const u32 *rate;\n> - int len;\n> -\n> /* too early to use cpu->of_node */\n> cn = of_get_cpu_node(cpu, NULL);\n> if (!cn) {\n> @@ -115,73 +70,13 @@ static void __init parse_dt_topology(void)\n> of_node_put(cn);\n> continue;\n\nAFAICT, this continue is now useless as it was there to skipe the cpu\ntable efficiency method\n\n> }\n> -\n> - cap_from_dt = false;\n> -\n> - for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)\n> - if (of_device_is_compatible(cn, cpu_eff->compatible))\n> - break;\n> -\n> - if (cpu_eff->compatible == NULL)\n> - continue;\n> -\n> - rate = of_get_property(cn, \"clock-frequency\", &len);\n> - if (!rate || len != 4) {\n> - pr_err(\"%s missing clock-frequency property\\n\",\n> - cn->full_name);\n> - continue;\n> - }\n> -\n> - capacity = ((be32_to_cpup(rate)) >> 20) * cpu_eff->efficiency;\n> -\n> - /* Save min capacity of the system */\n> - if (capacity < min_capacity)\n> - min_capacity = capacity;\n> -\n> - /* Save max capacity of the system */\n> - if (capacity > max_capacity)\n> - max_capacity = capacity;\n> -\n> - cpu_capacity(cpu) = capacity;\n> }\n>\n> - /* If min and max capacities are equals, we bypass the update of the\n> - * cpu_scale because all CPUs have the same capacity. Otherwise, we\n> - * compute a middle_capacity factor that will ensure that the capacity\n> - * of an 'average' CPU of the system will be as close as possible to\n> - * SCHED_CAPACITY_SCALE, which is the default value, but with the\n> - * constraint explained near table_efficiency[].\n> - */\n> - if (4*max_capacity < (3*(max_capacity + min_capacity)))\n> - middle_capacity = (min_capacity + max_capacity)\n> - >> (SCHED_CAPACITY_SHIFT+1);\n> - else\n> - middle_capacity = ((max_capacity / 3)\n> - >> (SCHED_CAPACITY_SHIFT-1)) + 1;\n> -\n> - if (cap_from_dt)\n> - topology_normalize_cpu_scale();\n\nWhy have you moved the call to topology_normalize_cpu_scale() from\nparse_dt_topology() to update_cpu_capacity() ?\n\nYou should keep it in parse_dt_topology() as itis part of the dt\nparsing sequence\n\n> -}\n> -\n> -/*\n> - * Look for a customed capacity of a CPU in the cpu_capacity table during the\n> - * boot. The update of all CPUs is in O(n^2) for heteregeneous system but the\n> - * function returns directly for SMP system.\n> - */\n> -static void update_cpu_capacity(unsigned int cpu)\n> -{\n> - if (!cpu_capacity(cpu) || cap_from_dt)\n> - return;\n> -\n> - topology_set_cpu_scale(cpu, cpu_capacity(cpu) / middle_capacity);\n> -\n> - pr_info(\"CPU%u: update cpu_capacity %lu\\n\",\n> - cpu, topology_get_cpu_scale(NULL, cpu));\n> + topology_normalize_cpu_scale();\n> }\n\nYou can probably just removed update_cpu_capacity()\n\n>\n> #else\n> static inline void parse_dt_topology(void) {}\n> -static inline void update_cpu_capacity(unsigned int cpuid) {}\n> #endif\n>\n> /*\n> @@ -277,8 +172,6 @@ void store_cpu_topology(unsigned int cpuid)\n>\n> update_siblings_masks(cpuid);\n>\n> - update_cpu_capacity(cpuid);\n> -\n> pr_info(\"CPU%u: thread %d, cpu %d, socket %d, mpidr %x\\n\",\n> cpuid, cpu_topology[cpuid].thread_id,\n> cpu_topology[cpuid].core_id,\n> --\n> 2.11.0\n>\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"E8pw3WAR\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xm2746jJnz9s06\n\tfor ;\n\tMon, 4 Sep 2017 17:49:36 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753270AbdIDHtf (ORCPT\n\t);\n\tMon, 4 Sep 2017 03:49:35 -0400","from mail-io0-f172.google.com ([209.85.223.172]:36206 \"EHLO\n\tmail-io0-f172.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753266AbdIDHtd (ORCPT\n\t); Mon, 4 Sep 2017 03:49:33 -0400","by mail-io0-f172.google.com with SMTP id f99so16920559ioi.3\n\tfor ;\n\tMon, 04 Sep 2017 00:49:33 -0700 (PDT)","by 10.107.180.84 with HTTP; Mon, 4 Sep 2017 00:49:11 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=fdX0yfFCavEMp/KPWKQBiapjJSOJQXKZNm+Kw8jWUjw=;\n\tb=E8pw3WARngorBiQ4qcijrUlXEugRPcNnThe3eG1BcwTxSHc5StKxOkEAjhMCnKSOdk\n\thtVvGAESV91rdyLiV1RK6L9iHNBUFGqq5nphM2Q3q10xyDVgSt44uay1mmS/TZbnj2wZ\n\tFYXuw4RuT+Ztb6eqy8zPgPItxO0YCIA7HESGs=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=fdX0yfFCavEMp/KPWKQBiapjJSOJQXKZNm+Kw8jWUjw=;\n\tb=BCyjhAVZHDqkEt11oL5VFfbREgfzkehnDatmJurmTiYAE+QZW4YvxoVCyxRrO1pGR5\n\tm9PaAfxy61UrTQNnEPQymbWH6DuY2W73EEeLiNJKkti1TvlrKhPfBGCOCjCCNI1LenZm\n\t58mz7VKbO51JwSLr1Y8SSbW/OvGvoHTXzRn9IkOASBG+el8uBWSFyiHyZukX9dvSCBOe\n\ttCUtqAgJtrEZdWKO58tC90zTFm1vzMhr+G0j7SQosvRk61im3sstuMP8KRaKtC7mtLJe\n\tjsh+aKCWb8EQXCH28kdMWJ2x4cdD6R/CX1dVe5K3+bzvsWJSRt+zK7/0HMVTigCwGTwN\n\ti2sg==","X-Gm-Message-State":"AHPjjUjlylhuu+5o3i0ITEmy2nY58++bwi8z8+dlnh0R4bwL+yYD8KO0\n\t/67Gj5pnP2G+1vU5phs+BQVYCrInTA1L","X-Google-Smtp-Source":"ADKCNb58MvsL5l2vZXWksfe73SlPnVJcPNcf/4Q7+F9O8xDl3at7gxTnmvL9Skcrs7pdPrG3j1hb1tViZ2TjUgOUJpM=","X-Received":"by 10.107.159.141 with SMTP id\n\ti135mr9974304ioe.268.1504511372477; \n\tMon, 04 Sep 2017 00:49:32 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170830144120.9312-2-dietmar.eggemann@arm.com>","References":"<20170830144120.9312-1-dietmar.eggemann@arm.com>\n\t<20170830144120.9312-2-dietmar.eggemann@arm.com>","From":"Vincent Guittot ","Date":"Mon, 4 Sep 2017 09:49:11 +0200","Message-ID":"","Subject":"Re: [PATCH 1/4] arm: topology: remove cpu_efficiency","To":"Dietmar Eggemann ","Cc":"linux-kernel ,\n\tLAK ,\n\t\"devicetree@vger.kernel.org\" ,\n\tlinux-samsung-soc ,\n\tlinux-renesas-soc@vger.kernel.org, Russell King , \n\tRob Herring , Mark Rutland ,\n\tKukjin Kim , Krzysztof Kozlowski , \n\tJuri Lelli ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1764042,"web_url":"http://patchwork.ozlabs.org/comment/1764042/","msgid":"<303d3f7b-5d64-e13a-c4f9-dd575958cafa@arm.com>","list_archive_url":null,"date":"2017-09-06T11:43:31","subject":"Re: [PATCH 1/4] arm: topology: remove cpu_efficiency","submitter":{"id":64545,"url":"http://patchwork.ozlabs.org/api/people/64545/","name":"Dietmar Eggemann","email":"dietmar.eggemann@arm.com"},"content":"Hi Vincent,\n\nOn 04/09/17 08:49, Vincent Guittot wrote:\n> Hi Dietmar,\n> \n> Removing cpu effificiency table looks good to me. Nevertheless, i have\n> some comments below for this patch.\n\nThanks for the review!\n\n> On 30 August 2017 at 16:41, Dietmar Eggemann wrote:\n>> Remove the 'cpu_efficiency/clock-frequency dt property' based solution\n>> to set cpu capacity which was only working for Cortex-A15/A7 arm\n>> big.LITTLE systems.\n>>\n>> I.e. the 'capacity-dmips-mhz' based solution is now the only one. It is\n>> shared between arm and arm64 and works for every big.LITTLE system no\n>> matter which core types it consists of.\n>>\n>> Cc: Russell King \n>> Cc: Vincent Guittot \n>> Cc: Juri Lelli \n>> Signed-off-by: Dietmar Eggemann \n>> ---\n>> arch/arm/kernel/topology.c | 113 ++-------------------------------------------\n>> 1 file changed, 3 insertions(+), 110 deletions(-)\n\n[...]\n\n>> @@ -115,73 +70,13 @@ static void __init parse_dt_topology(void)\n>> of_node_put(cn);\n>> continue;\n> \n> AFAICT, this continue is now useless as it was there to skipe the cpu\n> table efficiency method\n\nYou're right ... will remove it.\n\n[...]\n\n>> - if (cap_from_dt)\n>> - topology_normalize_cpu_scale();\n> \n> Why have you moved the call to topology_normalize_cpu_scale() from\n> parse_dt_topology() to update_cpu_capacity() ?\n\nDidn't move it ? It's still called from parse_dt_topology().\n\n> You should keep it in parse_dt_topology() as itis part of the dt\n> parsing sequence\n\nYes, this should be the case.\n\n[...]\n\n>> -/*\n>> - * Look for a customed capacity of a CPU in the cpu_capacity table during the\n>> - * boot. The update of all CPUs is in O(n^2) for heteregeneous system but the\n>> - * function returns directly for SMP system.\n>> - */\n>> -static void update_cpu_capacity(unsigned int cpu)\n>> -{\n>> - if (!cpu_capacity(cpu) || cap_from_dt)\n>> - return;\n>> -\n>> - topology_set_cpu_scale(cpu, cpu_capacity(cpu) / middle_capacity);\n>> -\n>> - pr_info(\"CPU%u: update cpu_capacity %lu\\n\",\n>> - cpu, topology_get_cpu_scale(NULL, cpu));\n>> + topology_normalize_cpu_scale();\n>> }\n> \n> You can probably just removed update_cpu_capacity()\n\nI did remove update_cpu_capacity(). Maybe the patch layout is confusing?\n\n[...]\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnMD93DDmz9sBW\n\tfor ;\n\tWed, 6 Sep 2017 21:43:37 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753347AbdIFLng (ORCPT\n\t);\n\tWed, 6 Sep 2017 07:43:36 -0400","from foss.arm.com ([217.140.101.70]:49454 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752831AbdIFLnf (ORCPT );\n\tWed, 6 Sep 2017 07:43:35 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3653480D;\n\tWed, 6 Sep 2017 04:43:34 -0700 (PDT)","from [10.1.210.41] (e107985-lin.cambridge.arm.com [10.1.210.41])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\t057163F540; Wed, 6 Sep 2017 04:43:31 -0700 (PDT)"],"Subject":"Re: [PATCH 1/4] arm: topology: remove cpu_efficiency","To":"Vincent Guittot ","Cc":"linux-kernel ,\n\tLAK ,\n\t\"devicetree@vger.kernel.org\" ,\n\tlinux-samsung-soc ,\n\tlinux-renesas-soc@vger.kernel.org, Russell King , \n\tRob Herring , Mark Rutland ,\n\tKukjin Kim , Krzysztof Kozlowski , \n\tJuri Lelli ","References":"<20170830144120.9312-1-dietmar.eggemann@arm.com>\n\t<20170830144120.9312-2-dietmar.eggemann@arm.com>\n\t","From":"Dietmar Eggemann ","Message-ID":"<303d3f7b-5d64-e13a-c4f9-dd575958cafa@arm.com>","Date":"Wed, 6 Sep 2017 12:43:31 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-GB","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1764046,"web_url":"http://patchwork.ozlabs.org/comment/1764046/","msgid":"<247b2b4a-c57a-eed9-c16f-fc7f1ef9f64f@arm.com>","list_archive_url":null,"date":"2017-09-06T11:47:21","subject":"Re: [PATCH 2/4] arm: dts: exynos: add exynos5420 cpu\n\tcapacity-dmips-mhz information","submitter":{"id":64545,"url":"http://patchwork.ozlabs.org/api/people/64545/","name":"Dietmar Eggemann","email":"dietmar.eggemann@arm.com"},"content":"On 03/09/17 20:56, Krzysztof Kozlowski wrote:\n> On Thu, Aug 31, 2017 at 11:36:07AM +0100, Dietmar Eggemann wrote:\n>> On 30/08/17 21:26, Krzysztof Kozlowski wrote:\n>>> On Wed, Aug 30, 2017 at 03:41:18PM +0100, Dietmar Eggemann wrote:\n\n[...]\n\n>>>> The patch has been tested on Samsung Chromebook 2 13\" (peach-pi, Exynos\n>>>> 5800).\n>>>>\n>>>> $ cat /sys/devices/system/cpu/cpu*/cpu_capacity\n>>>> 1024\n>>>> 1024\n>>>> 1024\n>>>> 1024\n>>>> 389\n>>>> 389\n>>>> 389\n>>>> 389\n>>>\n>>> I am missing something... shouldn't this be 539? Or is it scaled with\n>>> the clock-frequency (1 GHz) value?\n>>\n>> Yeah, the capacity-dmips-mhz dt value of 539 for the little cpus is\n>> scaled by 1.3/1.8 (max cpu capacity/ system wide max cpu capacity):\n>>\n>> 539 * 1.3/1.8 = 389\n>>\n>> This max cpu capacity scaling is part of both solutions, the 'cpu\n>> capacity-dmips-mhz' and the 'cpu_efficiency/clock-frequency dt property'\n>> one.\n>>\n>> The (original*) cpu capacity on a heterogeneous platform expresses uArch\n>> and max cpu frequency differences between the (logical) cpus of the\n>> system.\n>>\n>> * not further reduced by rt and/or irq pressure.\n>>\n>> [...]\n> \n> Thanks for explanation, looks fine for me. I'll take it after merge\n> window.\n\nNice, since the 'cpu capacity-dmips-mhz' is already supported for arm\n(and used by TC2 (vexpress-v2p-ca15_a7.dts)) this can be done\nindependently of the actual removal of the\n'cpu_efficiency/clock-frequency dt property' solution in patch 1/4.\n\n[..]\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnMJc4zJxz9sBZ\n\tfor ;\n\tWed, 6 Sep 2017 21:47:28 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752831AbdIFLr0 (ORCPT\n\t);\n\tWed, 6 Sep 2017 07:47:26 -0400","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:49518 \"EHLO\n\tfoss.arm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1753520AbdIFLrY (ORCPT );\n\tWed, 6 Sep 2017 07:47:24 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3C2C680D;\n\tWed, 6 Sep 2017 04:47:24 -0700 (PDT)","from [10.1.210.41] (e107985-lin.cambridge.arm.com [10.1.210.41])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\t455153F540; Wed, 6 Sep 2017 04:47:22 -0700 (PDT)"],"Subject":"Re: [PATCH 2/4] arm: dts: exynos: add exynos5420 cpu\n\tcapacity-dmips-mhz information","To":"Krzysztof Kozlowski ","Cc":"linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,\n\tlinux-renesas-soc@vger.kernel.org, Russell King , \n\tRob Herring , Mark Rutland ,\n\tKukjin Kim ,\n\tVincent Guittot ,\n\tJuri Lelli ","References":"<20170830144120.9312-1-dietmar.eggemann@arm.com>\n\t<20170830144120.9312-3-dietmar.eggemann@arm.com>\n\t<20170830202650.mdlxy2c3uwuq5vde@kozik-lap>\n\t<94c1d6c6-655a-2a63-1f01-06ac45990388@arm.com>\n\t<20170903195614.iwe7v6g3xsg7p6nf@kozik-lap>","From":"Dietmar Eggemann ","Message-ID":"<247b2b4a-c57a-eed9-c16f-fc7f1ef9f64f@arm.com>","Date":"Wed, 6 Sep 2017 12:47:21 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170903195614.iwe7v6g3xsg7p6nf@kozik-lap>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-GB","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1764069,"web_url":"http://patchwork.ozlabs.org/comment/1764069/","msgid":"","list_archive_url":null,"date":"2017-09-06T12:40:12","subject":"Re: [PATCH 1/4] arm: topology: remove cpu_efficiency","submitter":{"id":22608,"url":"http://patchwork.ozlabs.org/api/people/22608/","name":"Vincent Guittot","email":"vincent.guittot@linaro.org"},"content":"On 6 September 2017 at 13:43, Dietmar Eggemann wrote:\n> Hi Vincent,\n>\n> On 04/09/17 08:49, Vincent Guittot wrote:\n>> Hi Dietmar,\n>>\n>> Removing cpu effificiency table looks good to me. Nevertheless, i have\n>> some comments below for this patch.\n>\n> Thanks for the review!\n>\n>> On 30 August 2017 at 16:41, Dietmar Eggemann wrote:\n>>> Remove the 'cpu_efficiency/clock-frequency dt property' based solution\n>>> to set cpu capacity which was only working for Cortex-A15/A7 arm\n>>> big.LITTLE systems.\n>>>\n>>> I.e. the 'capacity-dmips-mhz' based solution is now the only one. It is\n>>> shared between arm and arm64 and works for every big.LITTLE system no\n>>> matter which core types it consists of.\n>>>\n>>> Cc: Russell King \n>>> Cc: Vincent Guittot \n>>> Cc: Juri Lelli \n>>> Signed-off-by: Dietmar Eggemann \n>>> ---\n>>> arch/arm/kernel/topology.c | 113 ++-------------------------------------------\n>>> 1 file changed, 3 insertions(+), 110 deletions(-)\n>\n> [...]\n>\n>>> @@ -115,73 +70,13 @@ static void __init parse_dt_topology(void)\n>>> of_node_put(cn);\n>>> continue;\n>>\n>> AFAICT, this continue is now useless as it was there to skipe the cpu\n>> table efficiency method\n>\n> You're right ... will remove it.\n>\n> [...]\n>\n>>> - if (cap_from_dt)\n>>> - topology_normalize_cpu_scale();\n>>\n>> Why have you moved the call to topology_normalize_cpu_scale() from\n>> parse_dt_topology() to update_cpu_capacity() ?\n>\n> Didn't move it ? It's still called from parse_dt_topology().\n>\n>> You should keep it in parse_dt_topology() as itis part of the dt\n>> parsing sequence\n>\n> Yes, this should be the case.\n>\n> [...]\n>\n>>> -/*\n>>> - * Look for a customed capacity of a CPU in the cpu_capacity table during the\n>>> - * boot. The update of all CPUs is in O(n^2) for heteregeneous system but the\n>>> - * function returns directly for SMP system.\n>>> - */\n>>> -static void update_cpu_capacity(unsigned int cpu)\n>>> -{\n>>> - if (!cpu_capacity(cpu) || cap_from_dt)\n>>> - return;\n>>> -\n>>> - topology_set_cpu_scale(cpu, cpu_capacity(cpu) / middle_capacity);\n>>> -\n>>> - pr_info(\"CPU%u: update cpu_capacity %lu\\n\",\n>>> - cpu, topology_get_cpu_scale(NULL, cpu));\n>>> + topology_normalize_cpu_scale();\n>>> }\n>>\n>> You can probably just removed update_cpu_capacity()\n>\n> I did remove update_cpu_capacity(). Maybe the patch layout is confusing?\n\nyes you're right I have been confused by the layout\n\n>\n> [...]\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"brHXwy3c\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xnNV32tBpz9t3Z\n\tfor ;\n\tWed, 6 Sep 2017 22:40:43 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753586AbdIFMkl (ORCPT\n\t);\n\tWed, 6 Sep 2017 08:40:41 -0400","from mail-it0-f52.google.com ([209.85.214.52]:37033 \"EHLO\n\tmail-it0-f52.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753554AbdIFMke (ORCPT\n\t); Wed, 6 Sep 2017 08:40:34 -0400","by mail-it0-f52.google.com with SMTP id k189so9810600itk.0\n\tfor ;\n\tWed, 06 Sep 2017 05:40:34 -0700 (PDT)","by 10.107.180.84 with HTTP; Wed, 6 Sep 2017 05:40:12 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=aeQSY0gJXm0PRvZz3dzvjQpl+q/tSFvw7NUGXgQHuuk=;\n\tb=brHXwy3c74qXDRGUQa2QKyhuLEWiiuQzooOJHWadlo1a1d6lK45xr0SgtaQXu7vAxl\n\tBPa6sxgYsMTHV2fPX77xwyLHn01LF7PzI91Q+2SEY3fevcYrrmCtZwApndtw3SdaLrJh\n\tubYhjwCDioYQJ2Akvt8PjcphzaN4UP/Mnv+2Y=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=aeQSY0gJXm0PRvZz3dzvjQpl+q/tSFvw7NUGXgQHuuk=;\n\tb=T/ZZNlArGjsdAsGiVNIWFQ7NHahqo4LqCVYj8wjq380crEW4CHobNGSpUjtulx1G2c\n\tqw65UtvQ//YS4lJJBvD+r/N7jvm6Shv0HpCp62lcUGokOnSIGnzoIPpeQVAcq2cRbbxx\n\tXY963gZREGa1LaoXwyZSHt3VHZfbSBz5I96mATn9brrsSmCaKma33ikLc2pxP/UiLpv8\n\tN4F2F/StJiFGBsMV9GaEul3z+/ThcSGcDAOjST5QDL59TiSdAnhR9Ur2j3J7UeS3QpA5\n\txJh9Ifnj9Fx9uJE9gjxEpcDHFjLHSwdzmR/ckS57lswWfKSFF+B5d8xt14n+NCHe3t/j\n\txzbA==","X-Gm-Message-State":"AHPjjUjkdF4XCZg1QWSlFZSMENkY4o3tq7/wLpRlCQKabOS4b2Xy4PKM\n\tsOCB2H0uPJbdnoBLNNn0QCJjPxslidJt","X-Google-Smtp-Source":"ADKCNb7nhseeLx4fIbtjbpEMC3B184Z9R7u1IDr0UXzb8aWmAIDJhyzd5/G017554sm5g+IBddgH+AhANksKV4y6VF0=","X-Received":"by 10.36.209.68 with SMTP id w65mr2798100itg.166.1504701633433; \n\tWed, 06 Sep 2017 05:40:33 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<303d3f7b-5d64-e13a-c4f9-dd575958cafa@arm.com>","References":"<20170830144120.9312-1-dietmar.eggemann@arm.com>\n\t<20170830144120.9312-2-dietmar.eggemann@arm.com>\n\t\n\t<303d3f7b-5d64-e13a-c4f9-dd575958cafa@arm.com>","From":"Vincent Guittot ","Date":"Wed, 6 Sep 2017 14:40:12 +0200","Message-ID":"","Subject":"Re: [PATCH 1/4] arm: topology: remove cpu_efficiency","To":"Dietmar Eggemann ","Cc":"linux-kernel ,\n\tLAK ,\n\t\"devicetree@vger.kernel.org\" ,\n\tlinux-samsung-soc ,\n\tlinux-renesas-soc@vger.kernel.org, Russell King , \n\tRob Herring , Mark Rutland ,\n\tKukjin Kim , Krzysztof Kozlowski , \n\tJuri Lelli ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1769673,"web_url":"http://patchwork.ozlabs.org/comment/1769673/","msgid":"<20170917073705.GC19716@kozik-book>","list_archive_url":null,"date":"2017-09-17T07:37:05","subject":"Re: [PATCH 2/4] arm: dts: exynos: add exynos5420 cpu\n\tcapacity-dmips-mhz information","submitter":{"id":68952,"url":"http://patchwork.ozlabs.org/api/people/68952/","name":"Krzysztof Kozlowski","email":"krzk@kernel.org"},"content":"On Wed, Aug 30, 2017 at 03:41:18PM +0100, Dietmar Eggemann wrote:\n> The following 'capacity-dmips-mhz' dt property values are used:\n> \n> Cortex-A15: 1024, Cortex-A7: 539\n> \n> They have been derived from the cpu_efficiency values:\n> \n> Cortex-A15: 3891, Cortex-A7: 2048\n> \n> by scaling them so that the Cortex-A15s (big cores) use 1024.\n> \n> The cpu_efficiency values were originally derived from the \"Big.LITTLE\n> Processing with ARM Cortex™-A15 & Cortex-A7\" white paper\n> (http://www.cl.cam.ac.uk/~rdm34/big.LITTLE.pdf). Table 1 lists 1.9x\n> (3891/2048) as the Cortex-A15 vs Cortex-A7 performance ratio for the\n> Dhrystone benchmark.\n> \n> The following platforms are affected once cpu-invariant accounting\n> support is re-connected to the task scheduler:\n> \n> arndale-octa, peach-pi, peach-pit, smdk5420\n> \n> The patch has been tested on Samsung Chromebook 2 13\" (peach-pi, Exynos\n> 5800).\n> \n> $ cat /sys/devices/system/cpu/cpu*/cpu_capacity\n> 1024\n> 1024\n> 1024\n> 1024\n> 389\n> 389\n> 389\n> 389\n> \n> The Cortex-A15 vs Cortex-A7 performance ratio is 1024/389 = 2.63.\n> \n> The values derived with the 'cpu_efficiency/clock-frequency dt property'\n> solution are:\n> \n> $ cat /sys/devices/system/cpu/cpu*/cpu_capacity\n> 1535\n> 1535\n> 1535\n> 1535\n> 448\n> 448\n> 448\n> 448\n> \n> The Cortex-A15 vs Cortex-A7 performance ratio is 1535/448 = 3.43.\n> \n> The discrepancy between 2.63 and 3.43 is due to the false assumption\n> when using the 'cpu_efficiency/clock-frequency dt property' solution\n> that the max cpu frequency of the little cpus is 1 GHZ and not 1.3 GHz.\n> The Cortex-A7 cluster runs with a max cpu frequency of 1.3 GHZ whereas\n> the 'clock-frequency' property value is set to 1 GHz.\n> \n> 3.43/1.3 = 2.64\n> \n> $ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq\n> 1800000\n> 1800000\n> 1800000\n> 1800000\n> 1300000 <-- max cpu frequency of the Cortex-A7s (little cores)\n> 1300000\n> 1300000\n> 1300000\n> \n> Running another benchmark (single-threaded sysbench affine to the\n> individual cpus) with performance cpufreq governor on the Samsung\n> Chromebook 2 13\" showed the following numbers:\n> \n> $ for i in `seq 0 7`; do taskset -c $i sysbench --test=cpu\n> --num-threads=1 --max-time=10 run | grep \"total number of events:\";\n> done\n> \n> total number of events: 1083\n> total number of events: 1085\n> total number of events: 1085\n> total number of events: 1085\n> total number of events: 454\n> total number of events: 454\n> total number of events: 454\n> total number of events: 454\n> \n> The Cortex-A15 vs Cortex-A7 performance ratio is 2.39, i.e. very close\n> to the one derived from the Dhrystone based one of the \"Big.LITTLE\n> Processing with ARM Cortex™-A15 & Cortex-A7\" white paper (2.63).\n> \n> We don't aim for exact values for the cpu capacity values. Besides the\n> CPI (Cycles Per Instruction), the instruction mix and whether the system\n> runs cpu-bound or memory-bound has an impact on the cpu capacity values\n> derived from these benchmark results.\n> \n> Cc: Rob Herring \n> Cc: Mark Rutland \n> Cc: Russell King \n> Cc: Kukjin Kim \n> Cc: Krzysztof Kozlowski \n> Signed-off-by: Dietmar Eggemann \n> ---\n> arch/arm/boot/dts/exynos5420-cpus.dtsi | 8 ++++++++\n> 1 file changed, 8 insertions(+)\n> \n\nThanks, applied (with s/arm/ARM/ change in subject).\n\nBest regards,\nKrzysztof\n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xw1Dn0Vlvz9sRm\n\tfor ;\n\tSun, 17 Sep 2017 17:37:13 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750885AbdIQHhL convert rfc822-to-8bit (ORCPT\n\t);\n\tSun, 17 Sep 2017 03:37:11 -0400","from mail-wm0-f53.google.com ([74.125.82.53]:44390 \"EHLO\n\tmail-wm0-f53.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750835AbdIQHhK (ORCPT\n\t); Sun, 17 Sep 2017 03:37:10 -0400","by mail-wm0-f53.google.com with SMTP id 189so8545527wmh.1;\n\tSun, 17 Sep 2017 00:37:08 -0700 (PDT)","from kozik-book (pub158181124008.dh-hfc.datazug.ch.\n\t[158.181.124.8]) by smtp.googlemail.com with ESMTPSA id\n\te24sm2851211edc.9.2017.09.17.00.37.07\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tSun, 17 Sep 2017 00:37:07 -0700 (PDT)"],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to:user-agent;\n\tbh=/S/Qg39vZNXy2u6O0Y4AgnK0U4N46xTzcIlwDNzIV4g=;\n\tb=iSg1w5RApRHYIjk2/RDhJGs9tsHzIcZufBqXyTyUS+8SypNgZemHi8V48dxJNw1Fnb\n\tteTMq1Nl5DMdfwYCiZ/pPoOrVdGUeSTm+SFYCE2HAaqeraSgxxg82Okzjm2WCX8kCKmQ\n\t2WpxAVveCEwvH3GOcym2djnWGRGl8NSuhK8sAjzWm2Ih0368Xk6hy3/XyCHZkP5XRxOE\n\tI7qw4CDqkjiMKL9Fsb4qYjel0Ft1iRYrABOyaKLMkQQkwon9jziPGgDWrSpYZ8ZGyhwy\n\tJCrrhRLjBbEaLxKR0yymI68+zV8GrzZmuUTWV4jr8C0ZSSy1sXC8OWPrLjkvo8Ie7a13\n\tvnSw==","X-Gm-Message-State":"AHPjjUjHDFrLLp//zqkm+Oyel/kSfTJrRvHEff/XI68/uJpzx4lDZ88h\n\tRT+vzgOACzn7CA==","X-Google-Smtp-Source":"ADKCNb4JXhZvy4vM7ukJZRDZpMfbJweDLza4yNX6MjZXOiuG1eys9sr6orQp9591xeWhIeFKn+vEPw==","X-Received":"by 10.80.167.131 with SMTP id i3mr26056523edc.173.1505633828227; \n\tSun, 17 Sep 2017 00:37:08 -0700 (PDT)","Date":"Sun, 17 Sep 2017 09:37:05 +0200","From":"Krzysztof Kozlowski ","To":"Dietmar Eggemann ","Cc":"linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,\n\tlinux-renesas-soc@vger.kernel.org, Russell King , \n\tRob Herring , Mark Rutland ,\n\tKukjin Kim ,\n\tVincent Guittot ,\n\tJuri Lelli ","Subject":"Re: [PATCH 2/4] arm: dts: exynos: add exynos5420 cpu\n\tcapacity-dmips-mhz information","Message-ID":"<20170917073705.GC19716@kozik-book>","References":"<20170830144120.9312-1-dietmar.eggemann@arm.com>\n\t<20170830144120.9312-3-dietmar.eggemann@arm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8BIT","In-Reply-To":"<20170830144120.9312-3-dietmar.eggemann@arm.com>","User-Agent":"Mutt/1.5.24 (2015-08-30)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1769675,"web_url":"http://patchwork.ozlabs.org/comment/1769675/","msgid":"<20170917073743.GD19716@kozik-book>","list_archive_url":null,"date":"2017-09-17T07:37:43","subject":"Re: [PATCH 3/4] arm: dts: exynos: add exynos5422 cpu\n\tcapacity-dmips-mhz information","submitter":{"id":68952,"url":"http://patchwork.ozlabs.org/api/people/68952/","name":"Krzysztof Kozlowski","email":"krzk@kernel.org"},"content":"On Wed, Aug 30, 2017 at 03:41:19PM +0100, Dietmar Eggemann wrote:\n> The following 'capacity-dmips-mhz' dt property values are used:\n> \n> Cortex-A15: 1024, Cortex-A7: 539\n> \n> They have been derived form the cpu_efficiency values:\n> \n> Cortex-A15: 3891, Cortex-A7: 2048\n> \n> by scaling them so that the Cortex-A15s (big cores) use 1024.\n> \n> The cpu_efficiency values were originally derived from the \"Big.LITTLE\n> Processing with ARM Cortex™-A15 & Cortex-A7\" white paper\n> (http://www.cl.cam.ac.uk/~rdm34/big.LITTLE.pdf). Table 1 lists 1.9x\n> (3891/2048) as the Cortex-A15 vs Cortex-A7 performance ratio for the\n> Dhrystone benchmark.\n> \n> The following platforms are affected once cpu-invariant accounting\n> support is re-connected to the task scheduler:\n> \n> odroidxu3, odroidxu3-lite, odroidxu4\n> \n> Cc: Rob Herring \n> Cc: Mark Rutland \n> Cc: Russell King \n> Cc: Kukjin Kim \n> Cc: Krzysztof Kozlowski \n> Signed-off-by: Dietmar Eggemann \n> ---\n> arch/arm/boot/dts/exynos5422-cpus.dtsi | 8 ++++++++\n> 1 file changed, 8 insertions(+)\n> \n\nThanks, applied.\n\nBest regards,\nKrzysztof\n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xw1Fl1Wgmz9s7M\n\tfor ;\n\tSun, 17 Sep 2017 17:38:03 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750861AbdIQHht convert rfc822-to-8bit (ORCPT\n\t);\n\tSun, 17 Sep 2017 03:37:49 -0400","from mail-wm0-f50.google.com ([74.125.82.50]:47874 \"EHLO\n\tmail-wm0-f50.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750803AbdIQHhr (ORCPT\n\t); Sun, 17 Sep 2017 03:37:47 -0400","by mail-wm0-f50.google.com with SMTP id 13so15814039wmq.2;\n\tSun, 17 Sep 2017 00:37:46 -0700 (PDT)","from kozik-book (pub158181124008.dh-hfc.datazug.ch.\n\t[158.181.124.8]) by smtp.googlemail.com with ESMTPSA id\n\tg59sm2688194ede.6.2017.09.17.00.37.44\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tSun, 17 Sep 2017 00:37:45 -0700 (PDT)"],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to:user-agent;\n\tbh=qj60CkHi15GXGNOEWkfbCzY9E7i0UiaVeGgwia94TQE=;\n\tb=anqwK+N13zVNcSHY2MBqXlBzY1I1bL5LFFQ9LxE4iVZ2WHEOO4QAYCVsrw+k+vsHMU\n\tZ7CObcU30wtHQj+siy8IKBQjdEHzNqYwiw2Exl8kYn6uSBKhI2ElMkqFTUyv0hijITJ+\n\t9KeWPbYO4c7mxgnJatX9snig5gr0JcErU18nSH9JoQM/40Q8ci2HKXMmrboEvPe5GeLR\n\tcLDQj2Y0+kANM3sUrRkvp0xHrTLe3B/5U83gmc2n8bCR5+uSR0zw0R6PZZA6fsBOJ/8Y\n\tyuOeUNkUTyhn4AVBdVCWUmmC28SvtJFSfv+qR7KoXDEdRlMOJPLDAWxLTbPI4JvU6+96\n\tQ8rw==","X-Gm-Message-State":"AHPjjUjKe5RWbJ7QhqQ3QoZzZMPoDytQvyALv9uQVWtMf8iMYiU6Htdc\n\tLceJJgqfUiBfYg==","X-Google-Smtp-Source":"ADKCNb5dYZpy5ZFo43PybwEm2DnBuzUcaNnSSD3ZME+DnP9sFlYjF9/7Go5MkTqIE+757/GCg2JEpg==","X-Received":"by 10.80.153.20 with SMTP id k20mr19280898edb.91.1505633866336; \n\tSun, 17 Sep 2017 00:37:46 -0700 (PDT)","Date":"Sun, 17 Sep 2017 09:37:43 +0200","From":"Krzysztof Kozlowski ","To":"Dietmar Eggemann ","Cc":"linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,\n\tlinux-renesas-soc@vger.kernel.org, Russell King , \n\tRob Herring , Mark Rutland ,\n\tKukjin Kim ,\n\tVincent Guittot ,\n\tJuri Lelli ","Subject":"Re: [PATCH 3/4] arm: dts: exynos: add exynos5422 cpu\n\tcapacity-dmips-mhz information","Message-ID":"<20170917073743.GD19716@kozik-book>","References":"<20170830144120.9312-1-dietmar.eggemann@arm.com>\n\t<20170830144120.9312-4-dietmar.eggemann@arm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8BIT","In-Reply-To":"<20170830144120.9312-4-dietmar.eggemann@arm.com>","User-Agent":"Mutt/1.5.24 (2015-08-30)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1769920,"web_url":"http://patchwork.ozlabs.org/comment/1769920/","msgid":"<20170918073946.GA9156@verge.net.au>","list_archive_url":null,"date":"2017-09-18T07:39:46","subject":"Re: [PATCH 4/4] arm: dts: r8a7790: add cpu capacity-dmips-mhz\n\tinformation","submitter":{"id":106,"url":"http://patchwork.ozlabs.org/api/people/106/","name":"Simon Horman","email":"horms@verge.net.au"},"content":"On Wed, Aug 30, 2017 at 03:41:20PM +0100, Dietmar Eggemann wrote:\n> The following 'capacity-dmips-mhz' dt property values are used:\n> \n> Cortex-A15: 1024, Cortex-A7: 539\n> \n> They have been derived form the cpu_efficiency values:\n> \n> Cortex-A15: 3891, Cortex-A7: 2048\n> \n> by scaling them so that the Cortex-A15s (big cores) use 1024.\n> \n> The cpu_efficiency values were originally derived from the \"Big.LITTLE\n> Processing with ARM Cortex™-A15 & Cortex-A7\" white paper\n> (http://www.cl.cam.ac.uk/~rdm34/big.LITTLE.pdf). Table 1 lists 1.9x\n> (3891/2048) as the Cortex-A15 vs Cortex-A7 performance ratio for the\n> Dhrystone benchmark.\n> \n> The following platform is affected once cpu-invariant accounting\n> support is re-connected to the task scheduler:\n\nThanks, applied for v4.15.\n\nMy understanding from the following comment in the cover letter is that not\ncurrently the case and this there is no behavioural change in applying this\npatch.\n\nFor the record I observed the following with and without this patch\napplied. I believe this is the expected result.\n\nv4.14-rc1\n# cat /sys/devices/system/cpu/cpu*/cpu_capacity\n1535\n1535\n1535\n1535\n1024\n1024\n1024\n1024\n\nv4.14-rc1 + patch\n# cat /sys/devices/system/cpu/cpu*/cpu_capacity\n1024\n1024\n1024\n1024\n539\n539\n539\n539\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=verge.net.au header.i=@verge.net.au\n\theader.b=\"Vc8mgN4y\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xwdFk0sb3z9ryQ\n\tfor ;\n\tMon, 18 Sep 2017 17:40:10 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750813AbdIRHkI (ORCPT\n\t);\n\tMon, 18 Sep 2017 03:40:08 -0400","from kirsty.vergenet.net ([202.4.237.240]:50474 \"EHLO\n\tkirsty.vergenet.net\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750757AbdIRHkH (ORCPT\n\t); Mon, 18 Sep 2017 03:40:07 -0400","from penelope.horms.nl (unknown [217.111.208.18])\n\tby kirsty.vergenet.net (Postfix) with ESMTPA id AE83725B80D;\n\tMon, 18 Sep 2017 17:40:04 +1000 (AEST)","by penelope.horms.nl (Postfix, from userid 7100)\n\tid BF45AE231ED; Mon, 18 Sep 2017 03:39:46 -0400 (EDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=simple/simple; d=verge.net.au; s=mail; \n\tt=1505720405; bh=Oc/9rw/Zthnvc5QLOG4VvIm/CE6MDJ/U0Bxfy85EY6g=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=Vc8mgN4yPKq2ZNiMS0VCxTD7h3qT4AC6YqEYLMU6FTW16l6u2eHcs1HaZPzIdXbHh\n\tlXdx94QH/cy9Cp15Mt2TqMi4Bri9O/EQexHMdl2DZuacuyPdzi08PzQGmuRC/N+uwp\n\tTKs3tteohu0KBKXUa0X/dIilx3n1mWjcd+ndbZhs=","Date":"Mon, 18 Sep 2017 09:39:46 +0200","From":"Simon Horman ","To":"Dietmar Eggemann ","Cc":"linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,\n\tlinux-renesas-soc@vger.kernel.org, Russell King , \n\tRob Herring , Mark Rutland ,\n\tKukjin Kim , Krzysztof Kozlowski , \n\tVincent Guittot ,\n\tJuri Lelli ","Subject":"Re: [PATCH 4/4] arm: dts: r8a7790: add cpu capacity-dmips-mhz\n\tinformation","Message-ID":"<20170918073946.GA9156@verge.net.au>","References":"<20170830144120.9312-1-dietmar.eggemann@arm.com>\n\t<20170830144120.9312-5-dietmar.eggemann@arm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20170830144120.9312-5-dietmar.eggemann@arm.com>","Organisation":"Horms Solutions BV","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1783104,"web_url":"http://patchwork.ozlabs.org/comment/1783104/","msgid":"","list_archive_url":null,"date":"2017-10-09T17:55:07","subject":"Re: [PATCH 4/4] arm: dts: r8a7790: add cpu capacity-dmips-mhz\n\tinformation","submitter":{"id":64545,"url":"http://patchwork.ozlabs.org/api/people/64545/","name":"Dietmar Eggemann","email":"dietmar.eggemann@arm.com"},"content":"On 18/09/17 08:39, Simon Horman wrote:\n> On Wed, Aug 30, 2017 at 03:41:20PM +0100, Dietmar Eggemann wrote:\n>> The following 'capacity-dmips-mhz' dt property values are used:\n>>\n>> Cortex-A15: 1024, Cortex-A7: 539\n>>\n>> They have been derived form the cpu_efficiency values:\n>>\n>> Cortex-A15: 3891, Cortex-A7: 2048\n>>\n>> by scaling them so that the Cortex-A15s (big cores) use 1024.\n>>\n>> The cpu_efficiency values were originally derived from the \"Big.LITTLE\n>> Processing with ARM Cortex™-A15 & Cortex-A7\" white paper\n>> (http://www.cl.cam.ac.uk/~rdm34/big.LITTLE.pdf). Table 1 lists 1.9x\n>> (3891/2048) as the Cortex-A15 vs Cortex-A7 performance ratio for the\n>> Dhrystone benchmark.\n>>\n>> The following platform is affected once cpu-invariant accounting\n>> support is re-connected to the task scheduler:\n> \n> Thanks, applied for v4.15.\n> \n> My understanding from the following comment in the cover letter is that not\n> currently the case and this there is no behavioural change in applying this\n> patch.\n> \n> For the record I observed the following with and without this patch\n> applied. I believe this is the expected result.\n> \n> v4.14-rc1\n> # cat /sys/devices/system/cpu/cpu*/cpu_capacity\n> 1535\n> 1535\n> 1535\n> 1535\n> 1024\n> 1024\n> 1024\n> 1024\n> \n> v4.14-rc1 + patch\n> # cat /sys/devices/system/cpu/cpu*/cpu_capacity\n> 1024\n> 1024\n> 1024\n> 1024\n> 539\n> 539\n> 539\n> 539\n\nThanks Simon! Yes, that is the expected behaviour. And sorry for not\nresponding earlier!\n\nWith exynos542{0,2} and r8a7790 switching to the 'capacity-dmips-mhz'\nbased solution in v4.15, I can push for removal of the cpu_efficency\ncode [patch 1/4].\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y9nvk1JWTz9tXw\n\tfor ;\n\tTue, 10 Oct 2017 04:55:14 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755250AbdJIRzM (ORCPT\n\t);\n\tMon, 9 Oct 2017 13:55:12 -0400","from foss.arm.com ([217.140.101.70]:33322 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1753921AbdJIRzL (ORCPT );\n\tMon, 9 Oct 2017 13:55:11 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BA2821529;\n\tMon, 9 Oct 2017 10:55:10 -0700 (PDT)","from [10.1.210.41] (e107985-lin.cambridge.arm.com [10.1.210.41])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\t9E2E83F483; Mon, 9 Oct 2017 10:55:08 -0700 (PDT)"],"Subject":"Re: [PATCH 4/4] arm: dts: r8a7790: add cpu capacity-dmips-mhz\n\tinformation","To":"Simon Horman ","Cc":"linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,\n\tlinux-renesas-soc@vger.kernel.org, Russell King , \n\tRob Herring , Mark Rutland ,\n\tKukjin Kim , Krzysztof Kozlowski , \n\tVincent Guittot ,\n\tJuri Lelli ","References":"<20170830144120.9312-1-dietmar.eggemann@arm.com>\n\t<20170830144120.9312-5-dietmar.eggemann@arm.com>\n\t<20170918073946.GA9156@verge.net.au>","From":"Dietmar Eggemann ","Message-ID":"","Date":"Mon, 9 Oct 2017 18:55:07 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170918073946.GA9156@verge.net.au>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-GB","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]