| 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
| ||
|
Message-id: <566A234E.50603@samsung.com>
Date: Fri, 11 Dec 2015 10:13:50 +0900
From: Krzysztof Kozlowski <k.kozlowski@...sung.com>
To: Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Cc: Thomas Abraham <thomas.ab@...sung.com>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Kukjin Kim <kgene.kim@...sung.com>,
Kukjin Kim <kgene@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.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>,
Javier Martinez Canillas <javier@....samsung.com>,
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
Subject: Re: [PATCH v4 4/8] ARM: Exynos: use generic cpufreq driver for
Exynos5420
On 10.12.2015 23:18, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Tuesday, December 08, 2015 04:36:12 PM Krzysztof Kozlowski wrote:
>> On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote:
>>> From: Thomas Abraham <thomas.ab@...sung.com>
>>>
>>> The new CPU clock type allows the use of cpufreq-dt driver
>>> for Exynos5420.
>>>
>>> Changes by Bartlomiej:
>>> - split Exynos5420 support from the original patch
>>> - disable cpufreq if big.LITTLE switcher support is enabled
>>> - switch to using cpufreq-dt driver
>>>
>>> Cc: Tomasz Figa <tomasz.figa@...il.com>
>>> Cc: Kukjin Kim <kgene.kim@...sung.com>
>>> Cc: Javier Martinez Canillas <javier.martinez@...labora.co.uk>
>>> Signed-off-by: Thomas Abraham <thomas.ab@...sung.com>
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
>>> ---
>>> arch/arm/mach-exynos/exynos.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>
>> I think this is actually now your patch, not Thomas any more. :)
>
> It seems so, I'll update the patch.
>
>>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>>> index 1c47aee..7a89c9d 100644
>>> --- a/arch/arm/mach-exynos/exynos.c
>>> +++ b/arch/arm/mach-exynos/exynos.c
>>> @@ -230,6 +230,9 @@ static const struct of_device_id exynos_cpufreq_matches[] = {
>>> { .compatible = "samsung,exynos4212", .data = "cpufreq-dt" },
>>> { .compatible = "samsung,exynos4412", .data = "cpufreq-dt" },
>>> { .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
>>> +#ifndef CONFIG_BL_SWITCHER
>>> + { .compatible = "samsung,exynos5420", .data = "cpufreq-dt" },
>>> +#endif
>>
>> Why not on BL_SWITCHER? Shouldn't be enough to disable ARM_DT_BL_CPUFREQ?
>
> ARM_DT_BL_CPUFREQ is not relevant here (it requires to be explicitly
> enabled by platform code, just like cpufreq-dt) and the dependency on
> !BL_SWITCHER is needed because when BL_SWITCHER is enabled big and
> LITTLE cores are grouped in pairs and presented as "virtual" CPUs to
> the system:
>
> ...
> [ 0.002630] CPU0: update cpu_capacity 448
> [ 0.002646] CPU0: thread -1, cpu 0, socket 1, mpidr 80000100
> [ 0.002835] Setting up static identity map for 0x40008280 - 0x400082d8
> [ 0.003106] ARM CCI driver probed
> [ 0.003351] Exynos MCPM support installed
> [ 0.045350] CPU1: update cpu_capacity 448
> [ 0.045358] CPU1: thread -1, cpu 1, socket 1, mpidr 80000101
> [ 0.060326] CPU2: update cpu_capacity 448
> [ 0.060334] CPU2: thread -1, cpu 2, socket 1, mpidr 80000102
> [ 0.075326] CPU3: update cpu_capacity 448
> [ 0.075334] CPU3: thread -1, cpu 3, socket 1, mpidr 80000103
> [ 0.090337] CPU4: update cpu_capacity 1535
> [ 0.090345] CPU4: thread -1, cpu 0, socket 0, mpidr 80000000
> [ 0.105314] CPU5: update cpu_capacity 1535
> [ 0.105321] CPU5: thread -1, cpu 1, socket 0, mpidr 80000001
> [ 0.120338] CPU6: update cpu_capacity 1535
> [ 0.120345] CPU6: thread -1, cpu 2, socket 0, mpidr 80000002
> [ 0.135330] CPU7: update cpu_capacity 1535
> [ 0.135338] CPU7: thread -1, cpu 3, socket 0, mpidr 80000003
> [ 0.135466] Brought up 8 CPUs
> ...
> [ 3.027498] big.LITTLE switcher initializing
> [ 3.031761] CPU0 paired with CPU7
> [ 3.035055] CPU1 paired with CPU6
> [ 3.038332] CPU2 paired with CPU5
> [ 3.041598] CPU3 paired with CPU4
> [ 3.044930] GIC ID for CPU 0 cluster 1 is 4
> [ 3.049078] GIC ID for CPU 1 cluster 1 is 5
> [ 3.053258] GIC ID for CPU 2 cluster 1 is 6
> [ 3.057370] GIC ID for CPU 3 cluster 1 is 7
> [ 3.061558] GIC ID for CPU 0 cluster 0 is 0
> [ 3.083336] IRQ53 no longer affine to CPU4
> [ 3.084336] CPU4: shutdown
> [ 3.107059] GIC ID for CPU 1 cluster 0 is 1
> [ 3.123303] IRQ54 no longer affine to CPU5
> [ 3.124213] CPU5: shutdown
> [ 3.146387] GIC ID for CPU 2 cluster 0 is 2
> [ 3.158143] cpu cpu0: 1100 MHz, 1250 mV --> 900 MHz, 1100 mV
> [ 3.168228] IRQ55 no longer affine to CPU6
> [ 3.169135] CPU6: shutdown
> [ 3.191485] GIC ID for CPU 3 cluster 0 is 3
> [ 3.208264] IRQ56 no longer affine to CPU7
> [ 3.209166] CPU7: shutdown
> [ 3.236752] big.LITTLE switcher initialized
> ...
>
> Only arm_big_little_dt driver knows how to handle this setup
> correctly. cpufreq-dt just treats "virtual" CPUs as a LITTLE
> ones. Thus when "virtual CPU"'s current core is switched to
> a big one cpufreq-dt is unable to update its voltage.
>
> [ I tried using BL_SWITCHER_DUMMY_IF functionality to simulate
> this with:
>
> echo 0,0 > /dev/b.L_switcher
>
> but it doesn't seem to work for some reason (from looking at
> arch/arm/common/bL_switcher_dummy_if.c code it seems that at
> least "bL_switcher_write" line should get logged but it does
> not happen). ]
Thank you for explanation, seems good approach.
Best regards,
Krzysztof
--
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/
Powered by blists - more mailing lists