> tristate "Hisilicon thermal driver"
> depends on (ARCH_HISI && CPU_THERMAL && OF) || COMPILE_TEST
> + select STUB_CLK_HI6220
Acked-by: Leo Yan
> help
> Enable this to plug hisilicon's thermal sensor driver into
cooling
device driver.
Signed-off-by: Leo Yan
---
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index eadf485..9fd2681 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
gurations yet.
Leo Yan (3):
clk: Hi6220: enable stub clock driver for ARCH_HISI
thermal: hisilicon: fix for dependency
arm64: defconfig: enable two common modules for power management
arch/arm64/configs/defconfig | 2 ++
drivers/clk/hisilicon/Kconfig | 1 +
drivers/thermal/Kconfig
dency with
CPU_THERMAL.
Signed-off-by: Leo Yan
---
drivers/thermal/Kconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2d702ca..91ebab3 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -177,8 +1
In current kernel config 'CONFIG_STUB_CLK_HI6220' is disabled by
default, as result stub clock driver has not been registered and
CPUFreq driver cannot work.
This patch is to enable stub clock driver in config for ARCH_HISI.
Reported-by: Dietmar Eggemann
Signed-off-by: Leo Yan
---
d
zone with CPU cooling device; and enable 'power allocator'
thermal governor.
Signed-off-by: Leo Yan
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index eadf485..c4f5948 100644
--- a/
Hi Catalin, Will,
On Thu, Sep 01, 2016 at 12:51:09PM +0800, Leo Yan wrote:
> Enable common modules for power management; one is to enable
> CPUFREQ_DT driver; the driver is used by many platforms by passing OPP
> table from device tree.
>
> Also enables thermal related drivers.
Function update_next_balance() is only used by idle balance, so its
parameter 'cpu_busy' is redundant and always be passed with 0.
This patch is to polish update_next_balance() to remove parameter
'cpu_busy'.
Signed-off-by: Leo Yan
---
kernel/sched/fair.c | 11 ++
Fix one minor typo in the comment: s/targer/target/.
Signed-off-by: Leo Yan
---
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5c883fe..4cb3547 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
have maximum load value is:
max_load = 2^29 * 88761 < 2^46
In theory after pass 46 periods we can ensure load value will be decayed
to zero. So this patch is to change maximum periods from 64 to 48.
Signed-off-by: Leo Yan
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+)
Hi Vincent,
Thanks for review.
On Fri, Aug 05, 2016 at 09:56:46AM +0200, Vincent Guittot wrote:
> Hi Leo,
>
> On 5 August 2016 at 08:34, Leo Yan wrote:
> >
> > In current code, decay_load() will consider to set load value to zero
> > after passing 32*64 ms. So th
have maximum load value is:
max_load = 2^29 * 88761 < 2^46
In theory after pass 46 periods we can ensure load value to be decayed
to zero. So this patch is to change maximum periods from 64 to 46.
Signed-off-by: Leo Yan
---
kernel/sched/fair.c | 10 +-
1 file changed, 9 inserti
In current kernel config 'CONFIG_STUB_CLK_HI6220' is disabled by
default, as result stub clock driver has not been registered and
CPUFreq driver cannot work.
This patch is to enable stub clock driver in config for ARCH_HISI.
Reported-by: Dietmar Eggemann
Signed-off-by: Leo Yan
---
d
Hi Amit,
On Mon, Aug 08, 2016 at 11:23:31AM +0530, Amit Kucheria wrote:
> On Mon, Aug 8, 2016 at 9:07 AM, Leo Yan wrote:
> > In current kernel config 'CONFIG_STUB_CLK_HI6220' is disabled by
> > default, as result stub clock driver has not been registered and
>
On Mon, Aug 08, 2016 at 08:12:21PM +0530, Amit Kucheria wrote:
[...]
> >> > diff --git a/drivers/clk/hisilicon/Kconfig
> >> > b/drivers/clk/hisilicon/Kconfig
> >> > index 3f537a0..9e0a95e 100644
> >> > --- a/drivers/clk/hisilicon/Kconfig
> >> > +++ b/drivers/clk/hisilicon/Kconfig
> >> > @@ -23,5
On Mon, Aug 08, 2016 at 09:36:32PM +0100, Daniel Thompson wrote:
[...]
> >My earlier patch focused on enabling the stub driver in the case the
> >thermal driver was enabled (and subsequently turning on HISI_THERMAL
> >in defconfig). The EAS profiling usecase to prevent thermal-throttling
> >from
c
> @@ -0,0 +1,198 @@
> +/*
> + * linux/drivers/thermal/hi3660_thermal.c
> + *
> + * Copyright (c) 2017 Hisilicon Limited.
> + * Copyright (c) 2017 Linaro Limited.
> + *
> + * Author: Tao Wang
> + * Author: Leo Yan
> + *
> + * This program is free software; you ca
Hi Mark,
On Tue, Oct 10, 2017 at 01:51:33PM -0600, Mathieu Poirier wrote:
> On 8 October 2017 at 09:35, Mark Rutland wrote:
> > Hi Leo,
> >
> > On Sun, Oct 08, 2017 at 10:12:46PM +0800, Leo Yan wrote:
> >> commit a88ce63b642c ("arm64: kexec: have own crash_smp_
On Tue, Oct 10, 2017 at 05:03:44PM +0100, Robin Murphy wrote:
> On 10/10/17 16:45, Mark Rutland wrote:
> > On Tue, Oct 10, 2017 at 10:27:25PM +0800, Leo Yan wrote:
> >> Hi Mark,
> >
> > Hi Leo,
> >
> >> I work mainline kernel on Hikey620 board, I fin
On Mon, Oct 16, 2017 at 03:35:46PM +0100, Robin Murphy wrote:
> On 16/10/17 15:26, Mark Rutland wrote:
> > On Mon, Oct 16, 2017 at 03:12:45PM +0100, Robin Murphy wrote:
> >> On 16/10/17 14:48, Mark Rutland wrote:
> >>> Hi Leo,
> >>>
> >>> O
On Mon, Oct 16, 2017 at 02:48:19PM +0100, Mark Rutland wrote:
> Hi Leo,
>
> On Mon, Oct 16, 2017 at 09:17:23AM +0800, Leo Yan wrote:
> > On Tue, Oct 10, 2017 at 05:03:44PM +0100, Robin Murphy wrote:
> > > On 10/10/17 16:45, Mark Rutland wrote:
> > > > On Tue, O
On Tue, Oct 17, 2017 at 10:32:21AM +0100, Ard Biesheuvel wrote:
[...]
> > AFAICT, erratum 836870 results in livelock rather than memory
> > corruption, so I think we can ignore that.
> >
> > I'm a little worried by erratum 843419. The VMAP_STACK patches changed
> > {adr,ldr}_this_cpu (and some us
proposition was to remove the multiple sensors
> > support, clean the driver, and re-introduce it if there is a need.
> >
> > If I remember correctly Leo, author of the driver, agreed on this. Leo ?
> >
> > Note, I'm not strongly against multiple sensors supp
On Mon, May 29, 2017 at 10:41:17AM -0600, Mathieu Poirier wrote:
> On 25 May 2017 at 09:57, Leo Yan wrote:
> > ARMv8 architecture reference manual (ARM DDI 0487A.k) Chapter H7 "The
> > Sample-based Profiling Extension" has description for sampling
> > registers, we
Hi Wei,
On Thu, May 25, 2017 at 11:57:15PM +0800, Leo Yan wrote:
> Bind debug module driver for Hi6220.
Could you ACK this patch? From Mathieu's previous suggestion, after
your confirmation he could pick up this patch.
If you want me to send a separate patch to you directly, also
Hi Andy, David,
[ + Nico ]
On Fri, May 26, 2017 at 12:04:13AM +0800, Leo Yan wrote:
> Add debug unit on Qualcomm msm8916 based platforms, including the
> DragonBoard 410c board.
Could you take a look for this patch? After get your ACK I think
Mathieu could help pick up this patch t
On Wed, Nov 01, 2017 at 04:48:50PM +0100, Michael Turquette wrote:
> Quoting Wei Xu (2017-10-13 10:57:02)
> > Hi Leo,
> >
> > On 2017/10/7 13:18, Leo Yan wrote:
> > > Hi Stephen, Wei,
> > >
> > > On Thu, Aug 31, 2017 at 06:33:01PM -0700, St
Hi Jassi,
On Wed, Oct 25, 2017 at 09:47:34AM +0530, Jassi Brar wrote:
> On Mon, Aug 7, 2017 at 2:47 PM, Zhong Kaihua wrote:
> > From: Kaihua Zhong
> >
> > Add mailbox driver for Hi3660.
> >
> > Signed-off-by: Leo Yan
> > Signed-off-by:
CMxMSET is used to set the channel's source and destination,
Hi3660 MBOX_IMASK_REG is used to mask interrupts for source and
destination and only clear bit for which master need receive
interrupt.
Though Hi3660 register definition is close to PL320 driver, but it's
seems hard to combine Hi3660 mailbox driver into PL320 driver
according to the register usage and flow. So I prefer to write one
dedicated Hi3660 mailbox driver.
Jassi, how about you think for this?
Thanks,
Leo Yan
On Tue, Oct 17, 2017 at 10:56:43AM +0100, Mark Rutland wrote:
> On Tue, Oct 17, 2017 at 05:36:58PM +0800, Leo Yan wrote:
> > On Tue, Oct 17, 2017 at 10:32:21AM +0100, Ard Biesheuvel wrote:
> >
> > [...]
> >
> > > > AFAICT, erratum 836870 results in liveloc
On Fri, Oct 27, 2017 at 09:38:44AM -0500, Rob Herring wrote:
> On Fri, Oct 27, 2017 at 02:15:02PM +0800, Kaihua Zhong wrote:
> > From: Leo Yan
> >
> > Introduce a binding for the Hi3660 mailbox controller, the mailbox is
> > used within application processor (AP),
V directly (even if via the sev()
> macro)...
>
> This SEV isn't ordered w.r.t. anything, and it's unclear what ordering you
> need, so this simply does not work.
I will leave your questions for Hisilicon colleagues, essentially
your questions are related with mailbox mechanism.
But I'd like to firstly get clear your question for "This SEV isn't
ordered w.r.t. anything". From my understanding, ARMv8 architecture
natually adds DMB before SEV so all previous register writing
opreations should be ensured to endpoint before SEV?
[...]
Thanks,
Leo Yan
Hi Mark,
On Mon, Oct 30, 2017 at 10:19:40AM +, Mark Rutland wrote:
> Hi,
>
> On Mon, Oct 30, 2017 at 12:45:06PM +0800, Leo Yan wrote:
> > On Fri, Oct 27, 2017 at 11:46:00AM +0100, Mark Rutland wrote:
> > > On Fri, Oct 27, 2017 at 02:15:03PM +0800, Kaihua Zhong wr
Hi Mark,
On Thu, Aug 27, 2015 at 05:31:09PM +0100, Mark Rutland wrote:
> On Wed, Aug 26, 2015 at 07:59:50AM +0100, Leo Yan wrote:
> > Hi Haojian,
> >
> > On Wed, Aug 26, 2015 at 09:25:41AM +0800, Haojian Zhuang wrote:
> > > On Wed, 2015-08-26 at 00:00 +0800, Leo Yan
On Sat, Aug 29, 2015 at 04:52:41PM +0800, Ding Tianhong wrote:
> Add initial dtsi file to support Hisilicon Hip05-D02 Board with
> support of CPUs in four clusters and each cluster has quard Cortex-A57.
>
> Also add dts file to support Hip05-D02 development board.
>
> Signed-off-by: Ding Tianhong
On Mon, Aug 31, 2015 at 09:44:38PM +0800, Ding Tianhong wrote:
> On 2015/8/31 21:12, Leo Yan wrote:
> > On Sat, Aug 29, 2015 at 04:52:41PM +0800, Ding Tianhong wrote:
> >> Add initial dtsi file to support Hisilicon Hip05-D02 Board with
> >> support of CPUs in four cl
ove the abstract common driver
layer and only commit driver dedicated for Hi6220
* According to Paul Bolle's review, fix typo issue for Kconfig and remove
unnecessary dependency with OF and fix minor for mailbox driver
* Refine a little for dts nodes
Leo Yan (4):
dt-bindings: mail
Enable SRAM node and stub clock node for Hi6220; furthermore
add the CPU's clock so it will be used by cpufreq-dt driver.
Signed-off-by: Leo Yan
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boo
receiving data, it will depend on the interrupt to notify
the channel has incoming message.
Now mailbox driver is used to send message to MCU to control dynamic
voltage and frequency scaling for CPU, GPU and DDR.
Signed-off-by: Leo Yan
---
drivers/mailbox/Kconfig | 8 +
drivers/mailbox
This patch add device mailbox node for Hi6220 in DT.
Signed-off-by: Leo Yan
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index e83802a..76560fa
Document the new compatible for Hisilicon Hi6220 mailbox driver.
Signed-off-by: Leo Yan
---
.../bindings/mailbox/hisilicon,hi6220-mailbox.txt | 57 ++
1 file changed, 57 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/hisilicon,hi6220
Select sp804 timer for ARCH_HISI, which is used as broadcast timer.
Signed-off-by: Leo Yan
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 23800a1..6d730fb 100644
--- a/arch/arm64
timer during idle states; Patch 4 registers CPU power down state
and cluster power down state.
Changes from v1:
* According to Sudeep's review, fix binding for idle-states
* According to Rob's review, due timers share same clock source with apb
clock, so just only pass one clock phand
Add sp804 timer for hi6220, so it can be used as broadcast timer.
Signed-off-by: Leo Yan
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index
Add cpu and cluster level's low power state for Hi6220.
Acked-by: Sudeep Holla
Signed-off-by: Leo Yan
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64
patch reserves these memory regions in DT.
Signed-off-by: Leo Yan
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
Hi Jassi,
Thanks for review.
On Fri, Oct 16, 2015 at 10:26:48AM +0530, Jassi Brar wrote:
> On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote:
>
> > +
> > +Mailbox Device Node:
> > +
> > +
> > +Required properties:
> > +---
On Fri, Oct 16, 2015 at 10:43:00AM +0530, Jassi Brar wrote:
> On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote:
>
> > +
> > +#define MBOX_CHAN_MAX 32
> > +#define MBOX_CHAN_NUM 2
> > +
> You mean the hardware has 32 channels but
On Fri, Oct 16, 2015 at 11:17:32AM +0530, Jassi Brar wrote:
> On Fri, Oct 16, 2015 at 10:59 AM, Leo Yan wrote:
> > On Fri, Oct 16, 2015 at 10:43:00AM +0530, Jassi Brar wrote:
> >> On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote:
> >>
> >> > +
> >&
On Fri, Oct 16, 2015 at 11:42:54AM +0530, Jassi Brar wrote:
> On 16 October 2015 at 11:38, Leo Yan wrote:
> > On Fri, Oct 16, 2015 at 11:17:32AM +0530, Jassi Brar wrote:
> >> On Fri, Oct 16, 2015 at 10:59 AM, Leo Yan wrote:
> >> > On Fri, Oct 16, 2015 at 10:4
Hi Rob,
On Tue, Oct 13, 2015 at 08:58:13AM +0800, Leo Yan wrote:
> On Hi6220, below memory regions in DDR have specific purpose:
>
> 0x05e0, - 0x05ef,: For MCU firmware using at runtime;
> 0x06df,f000 - 0x06df,: For mailbox message data;
> 0x0740,f000 - 0x074
Hi Kevin,
On Tue, Sep 01, 2015 at 05:28:03PM -0700, Kevin Hilman wrote:
> On Sun, Aug 2, 2015 at 6:13 PM, Leo Yan wrote:
> > On Hi6220, there have some clocks which can use mailbox channel to send
> > messages to power controller to change frequency; this includes CPU, GPU
>
So separately build stub clock driver and common clock driver for
Hi6220; and only let stub clock driver has the dependency with
CONFIG_MAILBOX.
Signed-off-by: Leo Yan
---
drivers/clk/hisilicon/Kconfig | 8 +++-
drivers/clk/hisilicon/Makefile | 3 ++-
2 files changed, 9 insertions(+), 2 del
On Tue, Jul 07, 2015 at 07:24:15PM +0100, Morten Rasmussen wrote:
> Let available compute capacity and estimated energy impact select
> wake-up target cpu when energy-aware scheduling is enabled and the
> system in not over-utilized (above the tipping point).
>
> energy_aware_wake_cpu() attempts t
On Tue, Jul 07, 2015 at 07:24:05PM +0100, Morten Rasmussen wrote:
> For energy-aware load-balancing decisions it is necessary to know the
> energy consumption estimates of groups of cpus. This patch introduces a
> basic function, sched_group_energy(), which estimates the energy
> consumption of the
On Thu, Sep 03, 2015 at 09:01:03AM -0700, Kevin Hilman wrote:
> Leo Yan writes:
>
> > The previous code, kernel builds Hi6220's common clock driver and stub
> > clock driver together. Stub clock driver has introduced the dependency
> > with CONFIG_MAILBOX, so k
4480 -5.229125 +6.059196
30%1.785221 6.974483 81.083312 0.548050 5.319929 83.551747
-1.237171 -1.654554 +2.468435
40%1.403247 6.474203 80.577176 0.467686 6.366482 81.983384
-0.935561 -0.107721 +1.406208
Leo Yan (2):
cpuidle: menu: Correct the criteria for stopping tick
rectness rather than
sched tick.
This patch is to check if it's a tick wakeup, it takes the CPU can
stay in the idle state for enough time so it gives high compensation
for the measured' interval, this can avoid tick impaction on the
correction factor array.
Cc: Daniel Lezcano
Cc
ll keep tick running.
For 'stop_tick_point', except we need to compare prediction period with
TICK_USEC, we also need consider from the perspective of deepest idle
state 'target_residency'. Finally, 'stop_tick_point' is coming from the
minimum value within the d
On Tue, Aug 07, 2018 at 10:27:02PM +0800, Leo Yan wrote:
> After Rafael's patch series 'sched/cpuidle: Idle loop rework' has been
> merged in mainline kernel, it perfectly resolved the Powernightmares
> issue [1] with not stopping the tick during the idle loop; we verifie
0.000 0.000 0.000 0.036 0.000 5.278 +0.036 +0.000 +5.278
71.894 8.013 0.059 1.509 0.026 8.002 -0.384 -7.987 +7.942
All 1.976 8.068 59.179 1.737 0.372 72.539 -0.239 -7.695 +13.360
Cc: Daniel Lezcano
Cc: Vincent Guittot
Signed-off-by: Leo Yan
---
kernel/sched/i
On Thu, Aug 09, 2018 at 01:47:27PM +0800, Leo Yan wrote:
> The idle loop stops tick by respecting the decision from cpuidle
> framework, if the condition 'need_resched()' is false without any task
> scheduling, the CPU keeps running in the loop in do_idle() and it h
On Thu, Aug 09, 2018 at 12:45:49PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 09, 2018 at 01:47:27PM +0800, Leo Yan wrote:
> > diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> > index 1a3e9bd..802286e 100644
> > --- a/kernel/sched/idle.c
> > +++ b/kernel/sched/id
On Thu, Aug 09, 2018 at 05:42:30PM +0200, Rafael J. Wysocki wrote:
[...]
> >> This issue can be easily reproduce with the case on Arm Hikey board: use
> >> CPU0 to send IPI to CPU7, CPU7 receives the IPI and in the callback
> >> function it start a hrtimer with 4ms, so the 4ms timer delta value c
le state before it will stay in idle
> > for long period.
>
> Fair enough, but in that case the governor will want the tick to be
> stopped, because expected_interval is TICK_USEC then, so I'm not sure
> how the patch helps?
Correct, I might introduce confusion at here and I mentioned in
another email I have one prerequisite patch [1]: "cpuidle: menu: Correct
the criteria for stopping tick", if without this dependency patch, the idle
governor will always stop the tick even it selects one shallow state.
Sorry when I sent patchs with [1], I didn't send to linux-pm mailing list,
do you want me to send these patches to linux-pm?
[...]
Thanks,
Leo Yan
[1] https://lkml.org/lkml/2018/8/7/407
4480 -5.229125 +6.059196
30%1.785221 6.974483 81.083312 0.548050 5.319929 83.551747
-1.237171 -1.654554 +2.468435
40%1.403247 6.474203 80.577176 0.467686 6.366482 81.983384
-0.935561 -0.107721 +1.406208
Leo Yan (2):
cpuidle: menu: Correct the criteria for stopping tick
ll keep tick running.
For 'stop_tick_point', except we need to compare prediction period with
TICK_USEC, we also need consider from the perspective of deepest idle
state 'target_residency'. Finally, 'stop_tick_point' is coming from the
minimum value within the d
rectness rather than
sched tick.
This patch is to check if it's a tick wakeup, it takes the CPU can
stay in the idle state for enough time so it gives high compensation
for the measured' interval, this can avoid tick impaction on the
correction factor array.
Cc: Daniel Lezcano
Cc
On Thu, Aug 09, 2018 at 11:31:46PM +0200, Rafael J . Wysocki wrote:
[...]
> > >> And I really would prefer to avoid restarting the tick here, because
> > >> it is overhead and quite likely unnecessary.
> > >
> > > I understand the logic when read the code, actually I did some experiments
> > > on
can decide their own policy for how to
use the tick in idle loop. This patch seems mixes two things and
finally it's possible to couple the implementation between idle loop
and 'menu' governor for sched tick usage.
I still think my patch to restart the tick is valid :)
Thanks,
On Thu, Aug 09, 2018 at 10:47:17PM +0200, Rafael J. Wysocki wrote:
> On Thu, Aug 9, 2018 at 7:20 PM, Leo Yan wrote:
> > The criteria for keeping tick running is the prediction duration is less
> > than TICK_USEC,
>
> Yes, because if the predicted idle duration is less t
On Fri, Aug 10, 2018 at 09:22:10AM +0200, Rafael J. Wysocki wrote:
> On Fri, Aug 10, 2018 at 9:13 AM, wrote:
> > On Thu, Aug 09, 2018 at 10:47:17PM +0200, Rafael J. Wysocki wrote:
> >> On Thu, Aug 9, 2018 at 7:20 PM, Leo Yan wrote:
>
> [cut]
>
> >> And th
On Fri, Aug 10, 2018 at 04:49:06PM +0800, Leo Yan wrote:
> On Fri, Aug 10, 2018 at 09:22:10AM +0200, Rafael J. Wysocki wrote:
> > On Fri, Aug 10, 2018 at 9:13 AM, wrote:
> > > On Thu, Aug 09, 2018 at 10:47:17PM +0200, Rafael J. Wysocki wrote:
> > >> On Thu, Aug 9, 2
o the time till the closest timer event if
> the tick is not running which will cause the selected idle states
> to always match the known CPU wakeup time.
>
> Also make it always indicate that the tick should be stopped in
> that case for consistency.
>
> Fixes: 87c9fe6ee495 (cpuid
> > duration to be equal to the time till the closest timer event if
> > > the tick is not running which will cause the selected idle states
> > > to always match the known CPU wakeup time.
> > >
> > > Also make it always indicate that the
gt; > > > !tick_nohz_tick_stopped())) {
> > > >
> > >
> > > The only effect of it would be setting stop_tick to false, but why
> > > would that matter?
> >
> > Please consider below situation, not sure if this case is existed or
> > not:
> >
> > step1: first time: enter one idle state with stopping tick;
> > step2: second time: select POLLING state and tick_nohz_tick_stopped()
> > is true;
> >
> > So in step2, it cannot set stop_tick to false with below sentence.
> >
> > > > > unsigned int delta_next_us = ktime_to_us(delta_next);
> > > > >
> > > > > *stop_tick = false;
>
> But setting *stop_tick has no effect as far as the current code is
> concerned (up to the bug fixed by the other patch).
Yeah.
> Also the POLLING state can only be selected if there are no other
> states matching delta_next available in that case which means that
> there will be a timer to break the polling loop soon enough (and BTW
> the polling has a built-in timeout too), so I don't really see a
> problem here.
Ah, now I understand the logic and I misunderstand the POLLING mode
before; now agree with this. Sorry for noise.
Thanks,
Leo Yan
l cause the selected idle states
> to always match the known CPU wakeup time.
>
> Also make it always indicate that the tick should be stopped in
> that case for consistency.
>
> Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with
> stopped tick)
> Re
On Sun, Aug 12, 2018 at 01:12:41PM +0200, Rafael J. Wysocki wrote:
> On Fri, Aug 10, 2018 at 11:03 AM wrote:
> >
> > On Fri, Aug 10, 2018 at 04:49:06PM +0800, Leo Yan wrote:
> > > On Fri, Aug 10, 2018 at 09:22:10AM +0200, Rafael J. Wysocki wrote:
> > > > On F
; is for the tick delta value and
it's a accurate estimation for tick event coming. This patch changes to
compare prediction with tick delta rather than comparing with the static
tick interval.
Signed-off-by: Leo Yan
---
drivers/cpuidle/governors/menu.c | 7 ---
1 file changed, 4 inserti
esent the idle duration predictions and
it can be used to compare with idle state target residency or tick
boundary for choosing idle state; we purely use 'expected_interval' to
record the expected interval value, which is mainly for interval
interrupt estimation.
Signed-off-by: Leo Yan
-
the testing, applied Rafael's patch 'cpuidle: menu: Handle
stopped tick more aggressively' [1] to avoid select unexpected shallow
state after tick has been stopped.
[1] https://lkml.org/lkml/2018/8/10/259
Leo Yan (5):
cpuidle: menu: Clean up variables usage in menu_select()
cpu
s one metric for consideration.
To achieve these purposes, this patch adds a new item 'tick_delta_us' in
struct menu_device to record tick delta value. This patch also is a
preparation for optimization stopping tick in sequential patches.
Signed-off-by: Leo Yan
---
drivers/cpuidle/g
the patch doesn't stop the tick for this case so can
avoid powernightmares issue.
Signed-off-by: Leo Yan
---
drivers/cpuidle/governors/menu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
inde
idle state calibration and thus save one indent
level in the loop.
Signed-off-by: Leo Yan
---
drivers/cpuidle/governors/menu.c | 76 ++--
1 file changed, 50 insertions(+), 26 deletions(-)
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle
nt stopping
tick decision making in 'menu' idle governor' [2], the testing result
supports the idle duration improvement, which shared in the cover letter.
Please help review and let me know if it's doable or not. Thanks for
the suggestion.
Thanks,
Leo Yan
[1] https://lkml.org/lkml/2018/8/12/84
[2] https://lkml.org/lkml/2018/8/12/82
tion, make it always indicate that the tick should be stopped
> if it has been stopped already for consistency.
>
> Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with
> stopped tick)
> Reported-by: Leo Yan
> Signed-off-by: Rafael J. Wysocki
> ---
> ->
>
> Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with
> stopped tick)
> Reported-by: Leo Yan
> Signed-off-by: Rafael J. Wysocki
> ---
>
> Commit 5ef499cd571c (cpuidle: menu: Handle stopped tick more aggressively) is
> in linux-next only at this p
On Wed, Aug 22, 2018 at 08:02:00PM +0800, Leo Yan wrote:
[...]
> > + if (!tick_nohz_tick_stopped()) {
> > + /*
> > +* If the state selected so far is shallow,
> > +* waking
Hi Arnaldo,
On Wed, Jul 11, 2018 at 03:45:39PM +0800, Leo Yan wrote:
Just want to confirm, I saw the first two patches in this serise have
been merged into perf/core branch [1], but the last 4 patches are
missed.
Could I know if you have trouble when you apply them? Or anything
need me to
On Tue, Jul 31, 2018 at 11:24:45AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jul 23, 2018 at 09:35:07AM +0800, leo@linaro.org escreveu:
> > Hi Arnaldo,
> >
> > On Wed, Jul 11, 2018 at 03:45:39PM +0800, Leo Yan wrote:
> >
> > Just want to confirm, I
That way it really look like an error message.
Will fix.
> Also debug_probe() uses dev_xyz() but everywhere else in the driver it is
> pr_xyz() - any specific reason for that? I suggest moving to dev_xyz().
Some logs are shared for all device instances, so I think should use
pr_xyz(); will spin a new version to change other places to use
dev_xyz() if the logs are for specific device instance.
> Otherwise things look good.
[...]
Thanks,
Leo Yan
|
pstate 2 : 873 ||
pstate 3 : 952 ||
pstate 4 : 0| |
Cc: Daniel Lezcano
Cc: Vincent Guitto
Hi Jesper,
On Wed, Jan 31, 2018 at 10:14:27AM +0100, Jesper Dangaard Brouer wrote:
> On Wed, 31 Jan 2018 02:29:59 +0800
> Leo Yan wrote:
>
> > CPU 0
> > State: Duration(ms) Distribution
> > cstate 0 : 47555|***
> +
> > + ret = hi3660_mbox_acquire_channel(chan);
> > + if (ret)
> > + return ret;
> > +
> > + return 0;
> > +}
> Do you not need to do "release channel" for shutdown() ?
>From my testing, the driver don't need "release channel" operations.
> .
> > +
> > +static int hi3660_mbox_send_data(struct mbox_chan *chan, void *msg)
> > +{
> > + return hi3660_mbox_send(chan, msg);
> >
> Please directly have hi3660_mbox_send as .send_data
Will fix.
Thanks,
Leo Yan
zed mailbox driver with "automatic ack" mode;
* Refined commit logs for patches;
Kaihua Zhong (2):
mailbox: Add support for Hi3660 mailbox
dts: arm64: Add mailbox binding for hi3660
Leo Yan (1):
dt-bindings: mailbox: Introduce Hi3660 controller binding
.../bindings/mailbox/hisili
Introduce a binding for the Hi3660 mailbox controller, the mailbox is
used within application processor (AP), communication processor (CP),
HIFI and MCU, etc.
Acked-by: Rob Herring
Signed-off-by: Leo Yan
---
.../bindings/mailbox/hisilicon,hi3660-mailbox.txt | 51 ++
1 file
ified. Later may enhance
this driver for interrupt mode (e.g. for supporting HIFI).
Signed-off-by: Leo Yan
Signed-off-by: Ruyi Wang
Signed-off-by: Kaihua Zhong
---
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailb
From: Kaihua Zhong
Add DT binding for mailbox driver.
Signed-off-by: Ruyi Wang
Signed-off-by: Kaihua Zhong
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
b/arch/arm64/boot/dts/hisilicon/hi366
nding.
Cc: Daniel Lezcano
Cc: Kevin Wang
Cc: Vincent Guittot
Signed-off-by: Leo Yan
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 32 ---
1 file changed, 4 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
b/arch/arm64/boot/dts
On Tue, Jan 09, 2018 at 11:41:26AM -0700, Mathieu Poirier wrote:
> On Thu, Dec 21, 2017 at 04:20:12PM +0800, Leo Yan wrote:
> > After kernel panic happens, coresight has many useful info can be used
> > for analysis. For example, the trace info from ETB RAM can be used to
&g
1 - 100 of 1764 matches
Mail list logo
