From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Javier Martinez Canillas <javier@osg.samsung.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Rob Herring <robh+dt@kernel.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Thomas Abraham <thomas.ab@samsung.com>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Mike Turquette <mturquette@baylibre.com>,
Kukjin Kim <kgene.kim@samsung.com>, Kukjin Kim <kgene@kernel.org>,
Ben Gamari <ben@smart-cactus.org>,
Tomasz Figa <tomasz.figa@gmail.com>,
Lukasz Majewski <l.majewski@samsung.com>,
Heiko Stuebner <heiko@sntech.de>,
Chanwoo Choi <cw00.choi@samsung.com>,
Kevin Hilman <khilman@linaro.org>,
Tobias Jakobi <tjakobi@math.uni-bielefeld.de>,
Anand Moon <linux.amoon@gmail.com>,
linux-samsung-soc@vger.kernel.org, linux-pm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Doug Anderson <dianders@chromium.org>,
Andreas Faerber <afaerber@suse.de>
Subject: Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
Date: Fri, 11 Dec 2015 14:28:43 +0900 [thread overview]
Message-ID: <566A5F0B.8040609@samsung.com> (raw)
In-Reply-To: <566A56DF.5040001@osg.samsung.com>
On 11.12.2015 13:53, Javier Martinez Canillas wrote:
> Hello Viresh,
>
> On 12/11/2015 01:38 AM, Viresh Kumar wrote:
>> 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.
>>
>
> I still fail to understand why the override is not a good way to solve
> the issue.
>
>> Either you should keep separate paths for both the SoCs, or can solve
>
> There's no point IMHO to duplicate the HW description since is the only
> difference between the Exynos5422 and Exynos5800 SoCs AFAIK.
Actually I think there is no nice way of making this as separate paths.
As Javier's mentioned, there aren't many differences. Currently the CPU
ordering is the only difference in DT.
Making it as separate path would create hierarchy like:
- exynos5420-based-board.dts
\- include: exynos5420.dtsi
\- include: exynos5.dtsi
\- include: exynos5420-cpu.dtsi (the cpus are not in exynos5420.dtsi)
- exynos5422-based-board.dts
\- include: exynos5420.dtsi
\- include: exynos5.dtsi
\- include: exynos5422-cpu.dtsi (the cpus are not in exynos5420.dtsi)
which of course is okay... except we keep the definition of CPUs
completely outside of main Exynos5420 DTSI. Then we have to include both
DTSI for each new DTS.
Other idea is to create artificial "exynos5420-common":
- exynos5420-based-board.dts
\- include: exynos5420.dtsi
\- include: exynos5420-common.dtsi
\- include: exynos5.dtsi
\- include: exynos5420-cpu.dtsi
- exynos5422-based-board.dts
\- include: exynos5422.dtsi
\- include: exynos5420-common.dtsi
\- include: exynos5.dtsi
\- include: exynos5422-cpu.dtsi
This is also confusing...
Any third idea?
Best regards,
KRzysztof
WARNING: multiple messages have this Message-ID (diff)
From: k.kozlowski@samsung.com (Krzysztof Kozlowski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
Date: Fri, 11 Dec 2015 14:28:43 +0900 [thread overview]
Message-ID: <566A5F0B.8040609@samsung.com> (raw)
In-Reply-To: <566A56DF.5040001@osg.samsung.com>
On 11.12.2015 13:53, Javier Martinez Canillas wrote:
> Hello Viresh,
>
> On 12/11/2015 01:38 AM, Viresh Kumar wrote:
>> 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 at 0 {
>> device_type = "cpu";
>> compatible = "arm,cortex-a15";
>> reg = <0x0>;
>> clock-frequency = <1800000000>;
>> cci-control-port = <&cci_control1>;
>> };
>>
>> cpu4: cpu at 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.
>>
>
> I still fail to understand why the override is not a good way to solve
> the issue.
>
>> Either you should keep separate paths for both the SoCs, or can solve
>
> There's no point IMHO to duplicate the HW description since is the only
> difference between the Exynos5422 and Exynos5800 SoCs AFAIK.
Actually I think there is no nice way of making this as separate paths.
As Javier's mentioned, there aren't many differences. Currently the CPU
ordering is the only difference in DT.
Making it as separate path would create hierarchy like:
- exynos5420-based-board.dts
\- include: exynos5420.dtsi
\- include: exynos5.dtsi
\- include: exynos5420-cpu.dtsi (the cpus are not in exynos5420.dtsi)
- exynos5422-based-board.dts
\- include: exynos5420.dtsi
\- include: exynos5.dtsi
\- include: exynos5422-cpu.dtsi (the cpus are not in exynos5420.dtsi)
which of course is okay... except we keep the definition of CPUs
completely outside of main Exynos5420 DTSI. Then we have to include both
DTSI for each new DTS.
Other idea is to create artificial "exynos5420-common":
- exynos5420-based-board.dts
\- include: exynos5420.dtsi
\- include: exynos5420-common.dtsi
\- include: exynos5.dtsi
\- include: exynos5420-cpu.dtsi
- exynos5422-based-board.dts
\- include: exynos5422.dtsi
\- include: exynos5420-common.dtsi
\- include: exynos5.dtsi
\- include: exynos5422-cpu.dtsi
This is also confusing...
Any third idea?
Best regards,
KRzysztof
next prev parent reply other threads:[~2015-12-11 5:28 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 16:58 [PATCH v5 0/7] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms Bartlomiej Zolnierkiewicz
2015-12-10 16:58 ` Bartlomiej Zolnierkiewicz
2015-12-10 16:58 ` [PATCH v5 1/7] ARM: dts: Exynos542x/5800: add cluster regulator supply properties Bartlomiej Zolnierkiewicz
2015-12-10 16:58 ` Bartlomiej Zolnierkiewicz
2015-12-11 1:16 ` Krzysztof Kozlowski
2015-12-11 1:16 ` Krzysztof Kozlowski
2015-12-10 16:58 ` [PATCH v5 2/7] clk: samsung: exynos5420: add cpu clock configuration data and instantiate cpu clock Bartlomiej Zolnierkiewicz
2015-12-10 16:58 ` Bartlomiej Zolnierkiewicz
2015-12-10 16:58 ` Bartlomiej Zolnierkiewicz
2015-12-10 16:58 ` [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties Bartlomiej Zolnierkiewicz
2015-12-10 16:58 ` Bartlomiej Zolnierkiewicz
2015-12-11 1:17 ` Krzysztof Kozlowski
2015-12-11 1:17 ` Krzysztof Kozlowski
2015-12-11 3:16 ` Viresh Kumar
2015-12-11 3:16 ` Viresh Kumar
2015-12-11 3:25 ` Javier Martinez Canillas
2015-12-11 3:25 ` Javier Martinez Canillas
2015-12-11 3:32 ` Viresh Kumar
2015-12-11 3:32 ` Viresh Kumar
2015-12-11 4:00 ` Krzysztof Kozlowski
2015-12-11 4:00 ` Krzysztof Kozlowski
2015-12-11 4:13 ` Viresh Kumar
2015-12-11 4:13 ` Viresh Kumar
2015-12-11 4:18 ` Krzysztof Kozlowski
2015-12-11 4:18 ` Krzysztof Kozlowski
2015-12-11 4:38 ` Viresh Kumar
2015-12-11 4:38 ` Viresh Kumar
2015-12-11 4:53 ` Krzysztof Kozlowski
2015-12-11 4:53 ` Krzysztof Kozlowski
2015-12-11 4:53 ` Javier Martinez Canillas
2015-12-11 4:53 ` Javier Martinez Canillas
2015-12-11 5:28 ` Krzysztof Kozlowski [this message]
2015-12-11 5:28 ` Krzysztof Kozlowski
2015-12-11 5:41 ` Viresh Kumar
2015-12-11 5:41 ` Viresh Kumar
2015-12-11 4:39 ` Viresh Kumar
2015-12-11 4:39 ` Viresh Kumar
2015-12-10 16:58 ` [PATCH v5 4/7] ARM: Exynos: use generic cpufreq driver for Exynos5420 Bartlomiej Zolnierkiewicz
2015-12-10 16:58 ` Bartlomiej Zolnierkiewicz
2015-12-11 1:18 ` Krzysztof Kozlowski
2015-12-11 1:18 ` Krzysztof Kozlowski
2015-12-10 16:58 ` [PATCH v5 5/7] clk: samsung: exynos5422/5800: fix cpu clock configuration data Bartlomiej Zolnierkiewicz
2015-12-10 16:58 ` Bartlomiej Zolnierkiewicz
2015-12-10 16:58 ` [PATCH v5 6/7] ARM: dts: Exynos5800: fix CPU OPP Bartlomiej Zolnierkiewicz
2015-12-10 16:58 ` Bartlomiej Zolnierkiewicz
2015-12-11 1:27 ` Krzysztof Kozlowski
2015-12-11 1:27 ` Krzysztof Kozlowski
2015-12-10 16:58 ` [PATCH v5 7/7] ARM: Exynos: use generic cpufreq driver for Exynos5422/5800 Bartlomiej Zolnierkiewicz
2015-12-10 16:58 ` Bartlomiej Zolnierkiewicz
2015-12-11 1:27 ` Krzysztof Kozlowski
2015-12-11 1:27 ` Krzysztof Kozlowski
2015-12-11 1:34 ` [PATCH v5 0/7] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms Krzysztof Kozlowski
2015-12-11 1:34 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=566A5F0B.8040609@samsung.com \
--to=k.kozlowski@samsung.com \
--cc=afaerber@suse.de \
--cc=b.zolnierkie@samsung.com \
--cc=ben@smart-cactus.org \
--cc=cw00.choi@samsung.com \
--cc=dianders@chromium.org \
--cc=heiko@sntech.de \
--cc=javier@osg.samsung.com \
--cc=kgene.kim@samsung.com \
--cc=kgene@kernel.org \
--cc=khilman@linaro.org \
--cc=l.majewski@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux.amoon@gmail.com \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=s.nawrocki@samsung.com \
--cc=thomas.ab@samsung.com \
--cc=tjakobi@math.uni-bielefeld.de \
--cc=tomasz.figa@gmail.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.