From: Xunlei Pang
As part of addressing the "y2038 problem" for in-kernel uses,
convert update_persistent_clock() to update_persistent_clock64(),
read_persistent_clock() to read_persistent_clock64() using
timespec64 for MN10300.
Add the common weak version of update_persistent_clock
ere're no objections with my approach, I'll go on with the work
to make all the rtc drivers under "drivers/rtc" y2038/y2106 safe.
NOTE: This patch series relies on the former patch series named:
"y2038 in-kernel interface changes for drivers/rtc".
Cc: John Stul
Currently the rtc_class_op's set_mmss() function takes a 32bit second
value (on 32bit systems), which is problematic for dates past y2038.
This patch resolves it by changing the interface and all users to use
y2038 safe time64_t.
Cc: John Stultz
Cc: Arnd Bergmann
Signed-off-by: Xunlei
()/rtc_time64_to_hw32()
- Use rtc_time64_to_hw32() to handle dryice_rtc_set_mmss()
After this patch, the drivers should not have any remaining y2038/y2106
issues.
Cc: John Stultz
Cc: Arnd Bergmann
Signed-off-by: Xunlei Pang
---
drivers/rtc/rtc-imxdi.c | 41
seconds since unix 1970 epoch.
There're also other ways to implement this function: For example,
some driver(vr41xx) implements the same logic using RTC_EPOCH_SET
ioctl and an rtc epoch offset variable. But the approach in this
patch is more flexible and common than that.
Cc: John Stultz
erts these two internal interfaces
of "mxc" to use safe time64_t first, so as to make some preparations
for the rtc_class_ops.set_mmss() conversion.
Currently, "mxc" is the only driver with such issue.
Cc: John Stultz
Cc: Arnd Bergmann
Signed-off-by: Xunlei Pang
---
On 2 December 2014 at 17:32, Jeremiah Mahler wrote:
> John,
>
> On Mon, Nov 24, 2014 at 08:35:45PM -0800, John Stultz wrote:
>> In commit 6067dc5a8c2b ("time: Avoid possible NTP adjustment mult
>> overflow") a new check was added to watch for adjustments that could
>> cause a mult overflow.
>>
>>
From: Xunlei Pang
rtc_set_mmss() uses "unsigned long" as its second parameter which
may have y2038 problem on 32-bit systems.
Change it to use time64_t.
All its call sites will be changed later(there are no problems
leaving these call sites untouched).
Signed-off-by: Xunlei Pang
--
From: Xunlei Pang
As part of addressing "y2038 problem" for in-kernel uses, this patch
converts update_persistent_clock() to update_persistent_clock64()
using timespec64 for both 32-bit and 64-bit sparc, since timekeeping
had already supported update_persistent_clock64().
Signed-off-
From: Xunlei Pang
- Remove "has_pushable_tasks(rq)".
Because for queued p, "!task_running(rq, p)" and "p->nr_cpus_allowed > 1"
already imply that "has_pushable_tasks(rq)" is true.
- Remove "!test_tsk_need_resched(rq->curr)".
The
From: Xunlei Pang
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT global scheduler does
From: Xunlei Pang
(Sync up the same behaviour as that of RT.)
We may suffer from extra dl overload rq due to the affinity,
so when the affinity of any runnable dl task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response
From: Xunlei Pang
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT global scheduler does
From: Xunlei Pang
Sync up the same behaviour as that of RT:
Remove "has_pushable_dl_tasks(rq)" and "!test_tsk_need_resched(rq->curr)".
Signed-off-by: Xunlei Pang
---
kernel/sched/deadline.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/sched/deadline.c b/
From: Xunlei Pang
- Remove "has_pushable_tasks(rq)".
Because for queued p, "!task_running(rq, p)" and "p->nr_cpus_allowed > 1"
already imply that "has_pushable_tasks(rq)" is true.
- Remove "!test_tsk_need_resched(rq->curr)".
The
d_task_dl(), we should add update_rq_clock() before
update_curr_dl().
Signed-off-by: Xunlei Pang
---
kernel/sched/deadline.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index e5db8c6..5648e62 100644
--- a/kernel/sched/deadline.c
+++
From: Xunlei Pang
timekeeping_inject_sleeptime64() is only used by RTC suspend/resume,
so embrace it in RTC related macros.
Signed-off-by: Xunlei Pang
---
v5 changes:
Remove CONFIG_RTC_CLASS.
kernel/time/timekeeping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/time
From: Xunlei Pang
If a system does not provide a persistent_clock(), the time
will be updated on resume by rtc_resume(). With the addition
of the non-stop clocksources for suspend timing, those systems
set the time on resume in timekeeping_resume(), but may not
provide a valid persistent_clock
From: Xunlei Pang
When there's no persistent clock, normally timekeeping_suspend_time
should always be zero, but this can break in timekeeping_suspend().
At T1, there was a system suspend, so old_delta was assigned T1.
After some time, one time adjustment happened, and xtime got the
value
From: Xunlei Pang
rtc_read_time() has already judged valid tm by rtc_valid_tm(),
so just remove it.
Signed-off-by: Xunlei Pang
---
drivers/rtc/class.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 74a943e..c29ba7e 100644
--- a/drivers
From: Xunlei Pang
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT global scheduler doesn&#
From: Xunlei Pang
Currently, SMP RT scheduler has some trouble in dealing with
equal prio cases.
For example, in check_preempt_equal_prio():
When RT1(current task) gets preempted by RT2, if there is a
migratable RT3 with same prio, RT3 will be pushed away instead
of RT1 afterwards, because RT1
From: Xunlei Pang
If there're multiple nodes with the same prio as @node, currently
plist_add() will add @node behind all of them. Now we need to add
@node before all of these nodes for SMP RT scheduler.
This patch adds a common __plist_add() for adding @node before or
after existing nodes
From: Xunlei Pang
As part of addressing in-kernel y2038 issues, this patch adds
read_persistent_clock64() and replaces all the call sites of
read_persistent_clock() with this function. This is a __weak
implementation, which simply calls the existing y2038 unsafe
read_persistent_clock().
This
From: Xunlei Pang
As part of addressing in-kernel y2038 issues, this patch adds
update_persistent_clock64() and replaces all the call sites of
update_persistent_clock() with this function. This is a __weak
implementation, which simply calls the existing y2038 unsafe
update_persistent_clock
From: Xunlei Pang
As part of addressing "y2038 problem" for in-kernel uses, this
patch adds the y2038-safe omap_read_persistent_clock64() using
timespec64.
Because we rely on some subsequent changes to convert arm multiarch
support, omap_read_persistent_clock() will be removed t
From: Xunlei Pang
As part of addressing in-kernel y2038 issues, this patch adds
read_boot_clock64() and replaces all the call sites of read_boot_clock()
with this function. This is a __weak implementation, which simply
calls the existing y2038 unsafe read_boot_clock().
This allows architecture
From: Xunlei Pang
read_boot_clock(), read_persistent_clock() and update_persistent_clock()
all use timespec which may have "y2038 problem", thus we are planning on
converting all of them to use timespec64.
The approach we're using is:
1) First of all, add the "__we
From: Xunlei Pang
Now we have all the read_boot_clock64() for all implementations,
it's time to remove read_boot_clock() completely from the kernel.
Signed-off-by: Xunlei Pang
---
read_persistent_clock() and update_persistent_clock() are way more
complex, so we will deal with them gradual
From: Xunlei Pang
As part of addressing "y2038 problem" for in-kernel uses, this
patch adds the y2038-safe tegra_read_persistent_clock64() using
timespec64.
Because we rely on some subsequent changes to convert arm multiarch
support, tegra_read_persistent_clock() will be removed the
From: Xunlei Pang
As part of addressing "y2038 problem" for in-kernel uses, this
patch converts read_boot_clock() to read_boot_clock64() and
read_persistent_clock() to read_persistent_clock64() using
timespec64 by converting clock_access_fn to use timespec64.
Signed-off-by: X
From: Xunlei Pang
As part of addressing "y2038 problem" for in-kernel uses, this
patch converts read_boot_clock() to read_boot_clock64() and
read_persistent_clock() to read_persistent_clock64() using
timespec64.
Since S390 is a 64bit architecture, also rename some timespec
to tim
Ping Peter
> From: Xunlei Pang
>
> In load_balance(), some members of lb_env will be assigned with
> new values in LBF_DST_PINNED case. But lb_env::flags may still
> retain LBF_ALL_PINNED if no proper tasks were found afterwards
> due to another balance, task affinity changi
Ping Juri
> From: Xunlei Pang
>
> In check_preempt_equal_dl(), cpudl_find() is called with a NULL
> later_mask, thus cpudl_find() here doesn't check cpudl::free_cpus
> at all.
>
> This patch takles this issue by always passing a non-NULL later_mask
> to cpudl_find
Ping Steve
> From: Xunlei Pang
>
> Currently, SMP RT scheduler has some trouble in dealing with
> equal prio cases.
>
> For example, in check_preempt_equal_prio():
> When RT1(current task) gets preempted by RT2, if there is a
> migratable RT3 with same prio, RT3 will be
Hi Vincent,
On 27 February 2015 at 23:54, Vincent Guittot
wrote:
> /**
> @@ -6432,18 +6435,19 @@ static inline void update_sd_lb_stats(struct lb_env
> *env, struct sd_lb_stats *sd
>
> /*
> * In case the child domain prefers tasks go to siblings
> -
Hi Vincent,
On 27 February 2015 at 23:54, Vincent Guittot
wrote:
> Monitor the usage level of each group of each sched_domain level. The usage is
> the portion of cpu_capacity_orig that is currently used on a CPU or group of
> CPUs. We use the utilization_load_avg to evaluate the usage level of e
From: Xunlei Pang
In load_balance(), some members of lb_env will be assigned with
new values in LBF_DST_PINNED case. But lb_env::flags may still
retain LBF_ALL_PINNED if no proper tasks were found afterwards
due to another balance, task affinity changing, etc, which can
really happen because
From: Xunlei Pang
In check_preempt_equal_dl(), cpudl_find() is called with a NULL
later_mask, thus cpudl_find() here doesn't check cpudl::free_cpus
at all.
This patch takles this issue by always passing a non-NULL later_mask
to cpudl_find(), thereby fixing this issue.
Signed-off-by: X
From: Xunlei Pang
Currently, RT global scheduling doesn't factor deadline
tasks, this may cause some problems.
See a case below:
On a 3 CPU system, CPU0 has one running deadline task,
CPU1 has one running low priority RT task or idle, CPU3
has one running high priority RT task. When anothe
From: Xunlei Pang
If a system does not provide a persistent_clock(), the time
will be updated on resume by rtc_resume(). With the addition
of the non-stop clocksources for suspend timing, those systems
set the time on resume in timekeeping_resume(), but may not
provide a valid persistent_clock
From: Xunlei Pang
When there's no persistent clock, normally timekeeping_suspend_time
should always be zero, but this can break in timekeeping_suspend().
At T1, there was a system suspend, so old_delta was assigned T1.
After some time, one time adjustment happened, and xtime got the
value
Hi Steve,
On 7 February 2015 at 05:09, Steven Rostedt wrote:
> On Thu, 5 Feb 2015 23:59:33 +0800
>> +
>> + if (task_running(rq, p) &&
>> + cpumask_test_cpu(task_cpu(p), new_mask) &&
>
> Why the check for task_cpu being in new_mask?
If the current cpu of this task is
On 8 February 2015 at 22:55, Xunlei Pang wrote:
> Hi Steve,
>
> On 7 February 2015 at 05:09, Steven Rostedt wrote:
>> On Thu, 5 Feb 2015 23:59:33 +0800
>>
>> if (task_running(rq, p)) {
>> if (cpumask_test_cpu() && cpupri_find())
ntil rt1 enters schedule(), this
definitely causes some/big response latency for rt2.
So, when doing set_cpus_allowed_rt(), if detecting such cases,
check to trigger a push behaviour.
Signed-off-by: Xunlei Pang
---
v2, v3:
Refine according to Steven Rostedt's comments.
ke
difference from check_preempt_equal_prio()
here is that we just don't care whether RT2 is migratable.
- Otherwise, if there's no rt task with the same priority as RT1,
RT1 will still be picked as the running task after the requeuing.
Signed-off-by: Xunlei Pang
---
kernel/sched/rt.c | 16 +++
From: Xunlei Pang
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT global scheduler doesn&#
From: Xunlei Pang
check_preempt_curr() doesn't call sched_class::check_preempt_curr
when the class of current is a higher level. So if there is a DL
task running when doing this for RT, check_preempt_equal_prio()
will definitely miss, which may result in some response latency
for this RT ta
From: Xunlei Pang
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT global scheduler doesn&#
From: Xunlei Pang
check_preempt_curr() doesn't call sched_class::check_preempt_curr
when the class of current is a higher level. So if there is a DL
task running when doing this for RT, check_preempt_equal_prio()
will definitely miss, which may result in some response latency
for this RT ta
From: Xunlei Pang
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT global scheduler doesn&#
Hi Steve,
On 4 February 2015 at 11:14, Steven Rostedt wrote:
> On Wed, 4 Feb 2015 09:12:20 +0800
> Xunlei Pang wrote:
>
>> From: Xunlei Pang
>>
>> + */
>> + cpumask_copy(&p->cpus_allowed, new_mask);
>>
Hi Steve,
On 4 February 2015 at 11:17, Steven Rostedt wrote:
> On Wed, 4 Feb 2015 09:12:21 +0800
> Xunlei Pang wrote:
>
>> From: Xunlei Pang
>>
>> check_preempt_curr() doesn't call sched_class::check_preempt_curr
>> when the class of current is a hig
Hi Peter, Steve,
Thanks for all your valuable sharing.
I'll keep them in mind.
Regards,
Xunlei
On 30 January 2015 at 03:23, Peter Zijlstra wrote:
> On Fri, Jan 30, 2015 at 12:42:47AM +0800, Xunlei Pang wrote:
>> On 27 January 2015 at 22:56, Steven Rostedt wrote:
>> > On
ber 2014 at 00:31, Xunlei Pang wrote:
> yield_task_dl() calls update_curr_dl() which calls start_dl_timer()
> to throttle current task. But yield_task_dl() doesn't update the rq
> clock which will cause start_dl_timer() to set the wrong dl_timer
> which may be much later than
On 4 February 2015 at 21:28, Xunlei Pang wrote:
> Hi Kirill,
>
> I've also sent out this similar patch to yours before,
> and I agree with you on this point :-)
>
> But with the latest modification which peter made,
> ( see: cebde6d681aa45f96111cfcffc1544cf2a0454ff
Ping ...
On 29 January 2015 at 23:59, Xunlei Pang wrote:
> From: Xunlei Pang
>
> If a system does not provide a persistent_clock(), the time
> will be updated on resume by rtc_resume(). With the addition
> of the non-stop clocksources for suspend timing, those systems
> set
Hi John,
On 11 February 2015 at 08:01, John Stultz wrote:
> On Thu, Jan 29, 2015 at 11:59 PM, Xunlei Pang wrote:
>> From: Xunlei Pang
>>
>> If a system does not provide a persistent_clock(), the time
>> will be updated on resume by rtc_resume(). With the
On 13 February 2015 at 07:31, Steven Rostedt wrote:
> On Sun, 8 Feb 2015 23:51:25 +0800
> Xunlei Pang wrote:
>
>
>> + if (new_weight > 1 &&
>> + rt_task(rq->curr) &&
>> + !test_tsk_need_resched(rq->curr)) {
>>
Hi steve,
On 13 February 2015 at 08:04, Steven Rostedt wrote:
> On Sun, 8 Feb 2015 23:51:26 +0800
> Xunlei Pang wrote:
>
>> check_preempt_curr() doesn't call sched_class::check_preempt_curr
>> when the class of current is a higher level.
>
> The above sentence
Hi Steve,
On 13 February 2015 at 11:55, Xunlei Pang wrote:
> Hi steve,
>
> On 13 February 2015 at 08:04, Steven Rostedt wrote:
>> On Sun, 8 Feb 2015 23:51:26 +0800
>> Xunlei Pang wrote:
>>
>>> check_preempt_curr() doesn't call sched_class::check_preemp
From: Xunlei Pang
rtc_read_time() has already judged valid tm by rtc_valid_tm(),
so just remove it.
Signed-off-by: Xunlei Pang
---
drivers/rtc/class.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 74a943e..c29ba7e 100644
--- a/drivers
From: Xunlei Pang
timekeeping_inject_sleeptime64() is only used by RTC suspend/resume,
so embrace it in RTC related macros.
Signed-off-by: Xunlei Pang
---
kernel/time/timekeeping.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
From: Xunlei Pang
When there's no persistent clock, normally timekeeping_suspend_time
should always be zero, but this can break in timekeeping_suspend().
At T1, there was a system suspend, so old_delta was assigned T1.
After some time, one time adjustment happened, and xtime got the
value
From: Xunlei Pang
If a system does not provide a persistent_clock(), the time
will be updated on resume by rtc_resume(). With the addition
of the non-stop clocksources for suspend timing, those systems
set the time on resume in timekeeping_resume(), but may not
provide a valid persistent_clock
Hi Thomas,
On 25 January 2015 at 01:07, Thomas Gleixner wrote:
> On Sat, 24 Jan 2015, Xunlei Pang wrote:
>
>> Before this, I tried to add some code to catch such problem at the
>> time of registering the clocksource, like using the
>> CLOCKSOURCE_MASK(), for example 64bit
ping Alessandro
On 21 January 2015 at 00:21, Xunlei Pang wrote:
> This patch series relies on a former patchset[1], it provides y2038/y2106
> safe rtc_class_ops.set_mmss64(), and converts some possible users of
> set_mmss()
> to use set_mmss64(), in the hope that making these us
From: Xunlei Pang
In check_preempt_equal_dl(), cpudl_find() is called with a NULL
later_mask, thus cpudl_find() here doesn't check cpudl::free_cpus
at all.
This patch takles this issue by always passing a non-NULL later_mask
to cpudl_find(), thereby fixing this issue.
Signed-off-by: X
From: Xunlei Pang
Currently, cpudl::free_cpus contains all cpus during init, see
cpudl_init(). When calling cpudl_find(), we have to mask rd->span
to avoid selecting the cpu outside current root domain, because
cpus_allowed is undependable when performing clustered scheduling
using the cpu
From: Xunlei Pang
Currently, RT global scheduling doesn't factor deadline
tasks, this may cause some problems.
See a case below:
On a 3 CPU system, CPU0 has one running deadline task,
CPU1 has one running low priority RT task or idle, CPU3
has one running high priority RT task. When anothe
From: Xunlei Pang
cpu_active_mask is rarely changeable, so remove this operation
to gain a little performance.
If there is a change in cpu_active_mask, rq_online_dl() and
rq_offline_dl() should take care of it normally, so cpudl::
free_cpus carries enough information for us.
For the rare case
From: Xunlei Pang
If a system does not provide a persistent_clock(), the time
will be updated on resume by rtc_resume(). With the addition
of the non-stop clocksources for suspend timing, those systems
set the time on resume in timekeeping_resume(), but may not
provide a valid persistent_clock
From: Xunlei Pang
rtc_read_time() has already judged valid tm by rtc_valid_tm(),
so just remove it.
Signed-off-by: Xunlei Pang
---
drivers/rtc/class.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 6100af5..7db4c90 100644
--- a/drivers
On 27 January 2015 at 22:56, Steven Rostedt wrote:
> On Tue, 27 Jan 2015 15:21:36 +0100
> Peter Zijlstra wrote:
>
>> On Mon, Jan 19, 2015 at 04:49:40AM +0000, Xunlei Pang wrote:
>> > In find_lowest_rq(), if we can't find a wake_affine cpu from
>> > sched_do
on afterwards,
migrate_task_rq_fair() will treat it as a blocked task due to its
non-zero decay_count, thereby adding its load to cfs_rq->removed_load
wrongly.
Thus, we must zero se->avg.decay_count in this case as well.
Signed-off-by: Xunlei Pang
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 inser
e any remaining
y2038/y2106 issues.
Signed-off-by: Xunlei Pang
---
drivers/rtc/rtc-mxc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-mxc.c b/drivers/rtc/rtc-mxc.c
index 83cba23..09d422b 100644
--- a/drivers/rtc/rtc-mxc.c
+++ b/drivers/rtc/rtc-mxc.c
@@ -
me preparations.
Signed-off-by: Xunlei Pang
---
drivers/rtc/rtc-mxc.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/rtc/rtc-mxc.c b/drivers/rtc/rtc-mxc.c
index a7b218f..83cba23 100644
--- a/drivers/rtc/rtc-mxc.c
+++ b/drivers/rtc/rtc-
change alpha_rtc_set_mmss() and remote_set_mmss() to use
rtc_class_ops's set_mmss64().
Signed-off-by: Xunlei Pang
---
arch/alpha/kernel/rtc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/alpha/kernel/rtc.c b/arch/alpha/kernel/rtc.c
index c8d284d..f5
e any remaining
y2038/y2106 issues.
Signed-off-by: Xunlei Pang
---
drivers/rtc/rtc-ab3100.c | 55
1 file changed, 27 insertions(+), 28 deletions(-)
diff --git a/drivers/rtc/rtc-ab3100.c b/drivers/rtc/rtc-ab3100.c
index 1d0340f..9b725c5 100644
ff-by: Xunlei Pang
---
drivers/rtc/rtc-mc13xxx.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/rtc/rtc-mc13xxx.c b/drivers/rtc/rtc-mc13xxx.c
index 5bce904b..32df1d8 100644
--- a/drivers/rtc/rtc-mc13xxx.c
+++ b/drivers/rtc/rtc-mc13xxx.c
@@ -
rtc_class_ops's set_alarm() shouldn't deal with the alarm date,
as this is handled in the rtc core.
See rtc_dev_ioctl()'s RTC_ALM_SET and RTC_WKALM_SET cases.
Signed-off-by: Xunlei Pang
---
drivers/rtc/rtc-mxc.c | 22 --
1 file changed, 4 insertions(+
est_mmss64" module
parameter.
Signed-off-by: Xunlei Pang
---
drivers/rtc/rtc-test.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-test.c b/drivers/rtc/rtc-test.c
index 8f86fa9..3a2da4c 100644
--- a/drivers/rtc/rtc-test.c
+++ b/drivers
: https://lkml.org/lkml/2014/11/27/341
[3] v2: https://lkml.org/lkml/2015/1/13/403
v2->v3:
* Remove get_seconds64(), use ktime_get_real_seconds() to replace get_seconds()
* Refine rtc-test.c
Xunlei Pang (8):
rtc: Provide y2038 safe rtc_class_ops.set_mmss() replacement
rtc/test: Update driver
fixed to use set_mmss64(), it can be removed when having no users.
Signed-off-by: Xunlei Pang
---
drivers/rtc/interface.c | 7 ++-
drivers/rtc/systohc.c | 5 -
include/linux/rtc.h | 1 +
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/interface.c b/driver
rtc_read_time() has already judged valid tm by rtc_valid_tm(),
so just remove it.
Signed-off-by: Xunlei Pang
---
drivers/rtc/class.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index c8f35a5..5953225 100644
--- a/drivers/rtc/class.c
+++ b
When doing timekeeping_resume(), if the nonstop clocksource wraps
back, "cycle_delta" will miss the wrap time.
So add a comment to indicate that if have this flag set, you are
aware that this nonstop clocksource won't wrap during suspension.
Signed-off-by: Xunlei Pang
---
the rtc_resume() logic thinking no one has set the time
and it then will over-write the suspend time again, which is not necessary
and only increases clock error.
So, fix this for rtc_resume().
Signed-off-by: Xunlei Pang
---
drivers/rtc/class.c | 2 +-
include/linux/timekeeping.h | 11
Currently, rtc-dev.c uses y2038 problematic rtc_tm_to_time()
and rtc_time_to_tm(). So replace them with their corresponding
y2038-safe versions: rtc_tm_to_time64() and rtc_time64_to_tm().
Reviewed-by: John Stultz
Reviewed-by: Arnd Bergmann
Signed-off-by: Xunlei Pang
---
drivers/rtc/rtc-dev.c
Currently, interface.c uses y2038 problematic rtc_tm_to_time()
and rtc_time_to_tm(). So replace them with their corresponding
y2038-safe versions: rtc_tm_to_time64() and rtc_time64_to_tm().
Reviewed-by: John Stultz
Reviewed-by: Arnd Bergmann
Signed-off-by: Xunlei Pang
---
drivers/rtc
rtc_read_time() has already judged valid tm by rtc_valid_tm(),
so just remove it.
Reviewed-by: John Stultz
Reviewed-by: Arnd Bergmann
Signed-off-by: Xunlei Pang
---
drivers/rtc/hctosys.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
: Xunlei Pang
---
drivers/rtc/systohc.c | 6 +++---
include/linux/rtc.h | 2 +-
kernel/time/ntp.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/systohc.c b/drivers/rtc/systohc.c
index e34a07b..22bbe2e 100644
--- a/drivers/rtc/systohc.c
+++ b/drivers/rtc
Reviewed-by: Arnd Bergmann
Signed-off-by: Xunlei Pang
---
drivers/rtc/hctosys.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
index 4aa60d7..2153b52 100644
--- a/drivers/rtc/hctosys.c
+++ b/drivers/rtc/hctosys.c
@@ -26,7
the rtc_resume() logic thinking no one has set
the time and it then will over-write the suspend time again,
which is not necessary and only increases clock error.
So, fix this for rtc_resume().
Signed-off-by: Xunlei Pang
---
v1->v2:
Modify according to Thomas' feedback.
drivers/rtc
o just add
a comment to indicate that if have this flag set, people
are aware that this nonstop clocksource won't wrap back
during system suspend/resume.
Signed-off-by: Xunlei Pang
---
include/linux/clocksource.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/cloc
rtc_read_time() has already judged valid tm by rtc_valid_tm(),
so just remove it.
Signed-off-by: Xunlei Pang
---
drivers/rtc/class.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 6100af5..7db4c90 100644
--- a/drivers/rtc/class.c
+++ b
From: Xunlei Pang
Currently, SMP RT scheduler has some trouble in dealing with
equal prio cases.
For example, in check_preempt_equal_prio():
When RT1(current task) gets preempted by RT2, if there is a
migratable RT3 with same prio, RT3 will be pushed away instead
of RT1 afterwards, because RT1
From: Xunlei Pang
If there're multiple nodes with the same prio as @node, currently
plist_add() will add @node behind all of them. Now we need to add
@node before all of these nodes for SMP RT scheduler.
This patch adds a common __plist_add() for adding @node before or
behind existing
From: Xunlei Pang
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT global scheduler doesn&#
On 2016/04/20/ at 20:25, Peter Zijlstra wrote:
> On Fri, Apr 15, 2016 at 10:19:12AM +0800, Xunlei Pang wrote:
>> On 2016/04/15 at 09:58, Xunlei Pang wrote:
>>> On 2016/04/14 at 23:31, Peter Zijlstra wrote:
>>>> On Thu, Apr 14, 2016 at 07:37:06PM +0800, Xunlei Pang wro
On 2016/04/20 at 21:19, Peter Zijlstra wrote:
> On Thu, Apr 14, 2016 at 07:37:03PM +0800, Xunlei Pang wrote:
>> +/* Updated under pi_lock and rtmutex lock */
>> struct rb_node *pi_waiters_leftmost;
>> +struct rb_node *pi_waiters_leftmost_copy;
&
201 - 300 of 553 matches
Mail list logo
