linux-kernel - Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151211043802.GP3612@ubuntu>
Date:	Fri, 11 Dec 2015 10:08:02 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Rob Herring <robh+dt@...nel.org>
Cc:	Javier Martinez Canillas <javier@....samsung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Thomas Abraham <thomas.ab@...sung.com>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Mike Turquette <mturquette@...libre.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Kukjin Kim <kgene@...nel.org>,
	Ben Gamari <ben@...rt-cactus.org>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Lukasz Majewski <l.majewski@...sung.com>,
	Heiko Stuebner <heiko@...ech.de>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	Kevin Hilman <khilman@...aro.org>,
	Tobias Jakobi <tjakobi@...h.uni-bielefeld.de>,
	Anand Moon <linux.amoon@...il.com>,
	linux-samsung-soc@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Doug Anderson <dianders@...omium.org>,
	Andreas Faerber <afaerber@...e.de>
Subject: Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties

On 11-12-15, 13:18, Krzysztof Kozlowski wrote:
> We had such configuration before (before df09df6f9ac3). I don't see any
> benefit in what you described. Where is the "thing" to be fixed? It is
> mixed up. The contiguous ordering is easier to read and more natural.

This is what you are doing today (keeping on one CPU per cluster to
simplify it):

		cpu0: cpu@0 {
			device_type = "cpu";
			compatible = "arm,cortex-a15";
			reg = <0x0>;
			clock-frequency = <1800000000>;
			cci-control-port = <&cci_control1>;
		};

		cpu4: cpu@100 {
			device_type = "cpu";
			compatible = "arm,cortex-a7";
			reg = <0x100>;
			clock-frequency = <1000000000>;
			cci-control-port = <&cci_control0>;
		};


Then you overwrite it with:

                &cpu0 {
                	device_type = "cpu";
                	compatible = "arm,cortex-a7";
                	reg = <0x100>;
                	clock-frequency = <1000000000>;
                	cci-control-port = <&cci_control0>;
                };
                
                &cpu4 {
                	device_type = "cpu";
                	compatible = "arm,cortex-a15";
                	reg = <0x0>;
                	clock-frequency = <1800000000>;
                	cci-control-port = <&cci_control1>;
                };


Don't you think this isn't the right way of solving problems?

The DT overwrite feature isn't there to do such kind of stuff, though
it doesn't stop you from doing that.

Either you should keep separate paths for both the SoCs, or can solve
it the way I suggested earlier.

This came up because in the current series you are doing this:

		cpu0: cpu@0 {
			compatible = "arm,cortex-a15";
                        operating-points-v2 = <&cpu0_opp_table>;
		};

		cpu4: cpu@100 {
			device_type = "cpu";
			compatible = "arm,cortex-a7";
                        operating-points-v2 = <&cpu1_opp_table>;
		};


Then you overwrite it with:

                &cpu0 {
                	compatible = "arm,cortex-a7";
                        operating-points-v2 = <&cpu1_opp_table>;
                };
                
                &cpu4 {
                	compatible = "arm,cortex-a15";
                        operating-points-v2 = <&cpu0_opp_table>;
                };
-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/