Re: sparc: bpf_jit: Move four assignments in bpf_jit_compile()

>> I hope so. - I propose to give the refactorings "Reduce scope of variable" >> and "Extract a function" (and the corresponding consequences) another look. > > So you _think_ it does. Come back with real proof. Which test environments would you find acceptable for further clarification? > I

Re: sparc: bpf_jit: Move four assignments in bpf_jit_compile()

>> I hope so. - I propose to give the refactorings "Reduce scope of variable" >> and "Extract a function" (and the corresponding consequences) another look. > > So you _think_ it does. Come back with real proof. Which test environments would you find acceptable for further clarification? > I

[PATCH] ARM: LPAE: initialize cachepolicy correctly

The cachepolicy variable gets initialized using a masked pmd So far, the pmd has been masked with flags valid for the 2-page table format. In the LPAE case, this lead to a wrong assumption of what the initial cachepolicy has been used. Later a check forces the cache policy to writealloc and prints

[PATCH] ARM: LPAE: initialize cachepolicy correctly

The cachepolicy variable gets initialized using a masked pmd So far, the pmd has been masked with flags valid for the 2-page table format. In the LPAE case, this lead to a wrong assumption of what the initial cachepolicy has been used. Later a check forces the cache policy to writealloc and prints

Re: [PATCH 2/4] sparc: bpf_jit: Move four assignments in bpf_jit_compile()

Hi Markus, On Sun, Sep 4, 2016 at 2:33 PM, SF Markus Elfring wrote: >>> Date: Sat, 3 Sep 2016 17:45:28 +0200 >>> >>> Move the assignments for four local variables a bit at the beginning >>> so that they will only be performed if a corresponding memory allocation

Re: [PATCH 2/4] sparc: bpf_jit: Move four assignments in bpf_jit_compile()

Hi Markus, On Sun, Sep 4, 2016 at 2:33 PM, SF Markus Elfring wrote: >>> Date: Sat, 3 Sep 2016 17:45:28 +0200 >>> >>> Move the assignments for four local variables a bit at the beginning >>> so that they will only be performed if a corresponding memory allocation >>> succeeded by this function. >

Re: [PATCH v2 0/3] Add Platform MHU mailbox driver for Amlogic GXBB

On Sun, Sep 4, 2016 at 2:15 AM, Kevin Hilman wrote: > On Fri, Sep 2, 2016 at 10:33 PM, Jassi Brar wrote: >> On Sat, Sep 3, 2016 at 5:04 AM, Kevin Hilman wrote: >>> Hi Jassi, >>> >>> Neil Armstrong

Re: [PATCH v2 0/3] Add Platform MHU mailbox driver for Amlogic GXBB

On Sun, Sep 4, 2016 at 2:15 AM, Kevin Hilman wrote: > On Fri, Sep 2, 2016 at 10:33 PM, Jassi Brar wrote: >> On Sat, Sep 3, 2016 at 5:04 AM, Kevin Hilman wrote: >>> Hi Jassi, >>> >>> Neil Armstrong writes: >>> In order to support Mailbox links for the Amlogic GXBB SoC, add a generic

Re: sparc: bpf_jit: Move four assignments in bpf_jit_compile()

Hi Markus, On Sun, Sep 4, 2016 at 3:00 PM, SF Markus Elfring wrote: >> Does this change improve the resulting binary? > > I hope so. - I propose to give the refactorings "Reduce scope of variable" > and "Extract a function" (and the corresponding consequences)

Re: sparc: bpf_jit: Move four assignments in bpf_jit_compile()

Hi Markus, On Sun, Sep 4, 2016 at 3:00 PM, SF Markus Elfring wrote: >> Does this change improve the resulting binary? > > I hope so. - I propose to give the refactorings "Reduce scope of variable" > and "Extract a function" (and the corresponding consequences) another look. So you _think_ it

arch/mips/include/asm/mach-cavium-octeon/mangle-port.h:19:40: error: right shift count >= width of type

Hi Steven, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 28e68154c5e2793123b248d38cf17b34dcb16d87 commit: 1685ddbe35cd4637f7f841d5f9755dd0470bd68d MIPS: Octeon: Changes to support readq()/writeq() usage. date:

arch/mips/include/asm/mach-cavium-octeon/mangle-port.h:19:40: error: right shift count >= width of type

Hi Steven, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 28e68154c5e2793123b248d38cf17b34dcb16d87 commit: 1685ddbe35cd4637f7f841d5f9755dd0470bd68d MIPS: Octeon: Changes to support readq()/writeq() usage. date:

Re: cmsg newgroup alt.sex.fetish.bool (was Re: [PATCH] arch: all: include: asm: bitops: Use bool instead of int for all bit test functions)

On Sun, Sep 04, 2016 at 06:36:56AM +0800, Chen Gang wrote: > And for all: shall I provide the proof for another archs? > > For me, Boolean gives additional chance to compiler to improve the code. Whereas for compiler it gives nothing. Not in those cases. > If the compiler can not improve the

Re: cmsg newgroup alt.sex.fetish.bool (was Re: [PATCH] arch: all: include: asm: bitops: Use bool instead of int for all bit test functions)

On Sun, Sep 04, 2016 at 06:36:56AM +0800, Chen Gang wrote: > And for all: shall I provide the proof for another archs? > > For me, Boolean gives additional chance to compiler to improve the code. Whereas for compiler it gives nothing. Not in those cases. > If the compiler can not improve the

[PATCH 1/3 (fix commit message)] perf tools: Recognize hugetlb mapping as anon mapping

Hugetlbfs mapping should be recognized as anon mapping so user has a chance to create /tmp/perf-.map file for symbol resolving. This patch utilizes MAP_HUGETLB to identify hugetlb mapping. After this patch, if perf is started before the program starts using huge pages (so perf gets MMAP2 events

[PATCH 1/3 (fix commit message)] perf tools: Recognize hugetlb mapping as anon mapping

Hugetlbfs mapping should be recognized as anon mapping so user has a chance to create /tmp/perf-.map file for symbol resolving. This patch utilizes MAP_HUGETLB to identify hugetlb mapping. After this patch, if perf is started before the program starts using huge pages (so perf gets MMAP2 events

Re: sparc: bpf_jit: Move four assignments in bpf_jit_compile()

> Does this change improve the resulting binary? I hope so. - I propose to give the refactorings "Reduce scope of variable" and "Extract a function" (and the corresponding consequences) another look. > I.e. does it make it smaller or faster? It is generally possible that a specific code

Re: sparc: bpf_jit: Move four assignments in bpf_jit_compile()

> Does this change improve the resulting binary? I hope so. - I propose to give the refactorings "Reduce scope of variable" and "Extract a function" (and the corresponding consequences) another look. > I.e. does it make it smaller or faster? It is generally possible that a specific code

[tip:timers/core 6/6] include/trace/events/alarmtimer.h:62: undefined reference to `rtc_ktime_to_tm'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core head: a0a6e06d545a753740c9d8d5ce2c4fdd3ab1c021 commit: a0a6e06d545a753740c9d8d5ce2c4fdd3ab1c021 [6/6] time: alarmtimer: Add tracepoints for alarmtimers config: s390-default_defconfig (attached as .config) compiler:

[tip:timers/core 6/6] include/trace/events/alarmtimer.h:62: undefined reference to `rtc_ktime_to_tm'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core head: a0a6e06d545a753740c9d8d5ce2c4fdd3ab1c021 commit: a0a6e06d545a753740c9d8d5ce2c4fdd3ab1c021 [6/6] time: alarmtimer: Add tracepoints for alarmtimers config: s390-default_defconfig (attached as .config) compiler:

Re: [PATCH 2/4] sparc: bpf_jit: Move four assignments in bpf_jit_compile()

>> Date: Sat, 3 Sep 2016 17:45:28 +0200 >> >> Move the assignments for four local variables a bit at the beginning >> so that they will only be performed if a corresponding memory allocation >> succeeded by this function. … >> @@ -362,10 +362,10 @@ do { *prog++ = BR_OPC | WDISP22(OFF);

Re: [PATCH 2/4] sparc: bpf_jit: Move four assignments in bpf_jit_compile()

>> Date: Sat, 3 Sep 2016 17:45:28 +0200 >> >> Move the assignments for four local variables a bit at the beginning >> so that they will only be performed if a corresponding memory allocation >> succeeded by this function. … >> @@ -362,10 +362,10 @@ do { *prog++ = BR_OPC | WDISP22(OFF);

[PATCH] video: mxsfb: get supply regulator optionally

The lcd-supply is meant to be optional, there are several device- trees not specifying it and the code handles error values silently. Therefor, avoid creating a dummy regulator (and the associated warning) by using devm_regulator_get_optional. While at it, document that fact also in the

[PATCH] video: mxsfb: get supply regulator optionally

The lcd-supply is meant to be optional, there are several device- trees not specifying it and the code handles error values silently. Therefor, avoid creating a dummy regulator (and the associated warning) by using devm_regulator_get_optional. While at it, document that fact also in the

Re: [PATCH 09/15] virtio-blk: Pass attribute group to device_add_disk

On Wed, Aug 17, 2016 at 03:15:09PM +0800, Fam Zheng wrote: > Previously after device_add_disk returns, the KOBJ_ADD uevent is already > emitted. Adding attributes after that is a poor usage of kobject, and > in practice may result in race conditions with userspace, for > example udev checks

[PATCH] usb: phy: generic: request regulator optionally

According to the device tree bindings the vcc-supply is optional. So far the driver did request the regulator using devm_regulator_get which creates a dummy regulator for convenience. Since we can have the supply unconnected, we should make use of the optional variant of the regulator call which

Re: [PATCH 09/15] virtio-blk: Pass attribute group to device_add_disk

On Wed, Aug 17, 2016 at 03:15:09PM +0800, Fam Zheng wrote: > Previously after device_add_disk returns, the KOBJ_ADD uevent is already > emitted. Adding attributes after that is a poor usage of kobject, and > in practice may result in race conditions with userspace, for > example udev checks

[PATCH] usb: phy: generic: request regulator optionally

According to the device tree bindings the vcc-supply is optional. So far the driver did request the regulator using devm_regulator_get which creates a dummy regulator for convenience. Since we can have the supply unconnected, we should make use of the optional variant of the regulator call which

Apply Today

Dear Sir/Madam, We give out urgent loan for business and personal purpose with 3% intrest rate applicable to all amount. Kindly get back to us via email: loa...@foxmail.com for further details on how to apply.

Apply Today

Dear Sir/Madam, We give out urgent loan for business and personal purpose with 3% intrest rate applicable to all amount. Kindly get back to us via email: loa...@foxmail.com for further details on how to apply.

Re: [PATCH 2/2] mwifiex: simplify length computation for some memset

Hi All, On Mon, Aug 8, 2016 at 5:39 PM, Christophe JAILLET wrote: > This patch should be a no-op. It just simplifies code by using the name of > a variable instead of its type when calling 'sizeof'. > > Signed-off-by: Christophe JAILLET

Re: [PATCH 2/2] mwifiex: simplify length computation for some memset

Hi All, On Mon, Aug 8, 2016 at 5:39 PM, Christophe JAILLET wrote: > This patch should be a no-op. It just simplifies code by using the name of > a variable instead of its type when calling 'sizeof'. > > Signed-off-by: Christophe JAILLET Reviewed-by: Julian Calaby Thanks, -- Julian Calaby

core.c:undefined reference to `fpu_save'

Hi Andrew, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 28e68154c5e2793123b248d38cf17b34dcb16d87 commit: c60f169202c7643991a8b4bfeea60e06843d5b5a arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h

core.c:undefined reference to `fpu_save'

Hi Andrew, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 28e68154c5e2793123b248d38cf17b34dcb16d87 commit: c60f169202c7643991a8b4bfeea60e06843d5b5a arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h

Re: [PATCH 2/4] sparc: bpf_jit: Move four assignments in bpf_jit_compile()

Hi Markus, On Sun, Sep 4, 2016 at 2:38 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 3 Sep 2016 17:45:28 +0200 > > Move the assignments for four local variables a bit at the beginning > so that they will only be

Re: [PATCH 2/4] sparc: bpf_jit: Move four assignments in bpf_jit_compile()

Hi Markus, On Sun, Sep 4, 2016 at 2:38 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 3 Sep 2016 17:45:28 +0200 > > Move the assignments for four local variables a bit at the beginning > so that they will only be performed if a corresponding memory allocation > succeeded by

Re: [PATCH] ath10k: Spelling and miscellaneous neatening

Hi All, On Tue, Aug 30, 2016 at 3:05 AM, Joe Perches wrote: > Correct some trivial comment typos. > Remove unnecessary parentheses in a long line. > Convert a return; before the end of a void function definition to just ; > > Signed-off-by: Joe Perches This

Re: [PATCH] ath10k: Spelling and miscellaneous neatening

Hi All, On Tue, Aug 30, 2016 at 3:05 AM, Joe Perches wrote: > Correct some trivial comment typos. > Remove unnecessary parentheses in a long line. > Convert a return; before the end of a void function definition to just ; > > Signed-off-by: Joe Perches This all looks correct to me. I wish

Re: [PATCH] staging: wilc1000: fix spelling mistake: "retyring" -> "retrying"

Hi All, On Sun, Aug 28, 2016 at 9:28 PM, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake in dev_err message > > Signed-off-by: Colin Ian King Reviewed-by: Julian Calaby

Re: [PATCH] staging: wilc1000: fix spelling mistake: "retyring" -> "retrying"

Hi All, On Sun, Aug 28, 2016 at 9:28 PM, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake in dev_err message > > Signed-off-by: Colin Ian King Reviewed-by: Julian Calaby Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile:

Re: [PATCH] rtl8xxxu: fix spelling mistake "firmare" -> "firmware"

Hi All, On Sun, Sep 4, 2016 at 2:43 AM, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistakes in dev_dbg message. > > Signed-off-by: Colin Ian King Reviewed-by: Julian Calaby

Re: [PATCH] rtl8xxxu: fix spelling mistake "firmare" -> "firmware"

Hi All, On Sun, Sep 4, 2016 at 2:43 AM, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistakes in dev_dbg message. > > Signed-off-by: Colin Ian King Reviewed-by: Julian Calaby Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile:

Re: [RFC 2/4] mm: replace TIF_MEMDIE checks by tsk_is_oom_victim

Michal Hocko wrote: > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 9ee178ba7b71..df58733ca48e 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -1899,7 +1899,7 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t > gfp_mask, >* bypass the last charges so that they

Re: [RFC 3/4] mm, oom: do not rely on TIF_MEMDIE for exit_oom_victim

Michal Hocko wrote: > mark_oom_victim and exit_oom_victim are used for oom_killer_disable > which should block as long as there any any oom victims alive. Up to now > we have relied on TIF_MEMDIE task flag to count how many oom victim > we have. This is not optimal because only one thread receives

Re: [RFC 2/4] mm: replace TIF_MEMDIE checks by tsk_is_oom_victim

Michal Hocko wrote: > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 9ee178ba7b71..df58733ca48e 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -1899,7 +1899,7 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t > gfp_mask, >* bypass the last charges so that they

Re: [RFC 3/4] mm, oom: do not rely on TIF_MEMDIE for exit_oom_victim

Michal Hocko wrote: > mark_oom_victim and exit_oom_victim are used for oom_killer_disable > which should block as long as there any any oom victims alive. Up to now > we have relied on TIF_MEMDIE task flag to count how many oom victim > we have. This is not optimal because only one thread receives

Re: [RFC 1/4] mm, oom: do not rely on TIF_MEMDIE for memory reserves access

Michal Hocko wrote: > @@ -816,7 +816,8 @@ static void oom_kill_process(struct oom_control *oc, > const char *message) > > /* >* If the task is already exiting, don't alarm the sysadmin or kill > - * its children or threads, just set TIF_MEMDIE so it can die quickly > + *

drivers/media/v4l2-core/videobuf2-dma-contig.c:486:2: error: implicit declaration of function 'dma_get_cache_alignment'

Hi Hans, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 28e68154c5e2793123b248d38cf17b34dcb16d87 commit: c1023ba74fc77dc56dc317bd98f5060aab889ac1 [media] drivers/media/platform/Kconfig: fix VIDEO_MEDIATEK_VCODEC

Re: [RFC 1/4] mm, oom: do not rely on TIF_MEMDIE for memory reserves access

Michal Hocko wrote: > @@ -816,7 +816,8 @@ static void oom_kill_process(struct oom_control *oc, > const char *message) > > /* >* If the task is already exiting, don't alarm the sysadmin or kill > - * its children or threads, just set TIF_MEMDIE so it can die quickly > + *

drivers/media/v4l2-core/videobuf2-dma-contig.c:486:2: error: implicit declaration of function 'dma_get_cache_alignment'

Hi Hans, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 28e68154c5e2793123b248d38cf17b34dcb16d87 commit: c1023ba74fc77dc56dc317bd98f5060aab889ac1 [media] drivers/media/platform/Kconfig: fix VIDEO_MEDIATEK_VCODEC

[RFC v5 16/23] clockevents: clockevents_program_min_delta(): don't set ->next_event

Currently, clockevents_program_min_delta() sets a clockevent device's ->next_event to the point in time where the minimum delta would actually expire: delta = dev->min_delta_ns; dev->next_event = ktime_add_ns(ktime_get(), delta); For your reference, this is so since the initial advent of

[RFC v5 16/23] clockevents: clockevents_program_min_delta(): don't set ->next_event

Currently, clockevents_program_min_delta() sets a clockevent device's ->next_event to the point in time where the minimum delta would actually expire: delta = dev->min_delta_ns; dev->next_event = ktime_add_ns(ktime_get(), delta); For your reference, this is so since the initial advent of

[RFC v5 14/23] clockevents: decouple ->max_delta_ns from ->max_delta_ticks

Before converting the given delta from ns to cycles by means of the mult/shift pair, clockevents_program_event() enforces it to be less or equal than ->max_delta_ns. Simplified, this reads as delta = min(delta, dev->max_delta_ns); clc = (delta * dev->mult) >> dev->shift; A device's

Re: [Question] about patch: don't use [delayed_]work_pending()

Hi, [no properly binding reference via In-Reply-To: available thus manually re-creating, sorry] https://lkml.org/lkml/2016/9/2/335 I came up with the following somewhat random thoughts: *** this treatment is exclusive to a single use case, i.e. not covering things consistently (API-wide) >

[RFC v5 20/23] clockevents: purge ->min_delta_ns

The struct clock_event_device's ->min_delta_ns member isn't used anymore. Purge it. In __clockevents_update_bounds(), shortcut the ->min_delta_ticks => ->min_delta_ns => ->min_delta_ticks_adjusted calculation detour -- it had been made solely for the purpose of ensuring that

Re: [Question] about patch: don't use [delayed_]work_pending()

Hi, [no properly binding reference via In-Reply-To: available thus manually re-creating, sorry] https://lkml.org/lkml/2016/9/2/335 I came up with the following somewhat random thoughts: *** this treatment is exclusive to a single use case, i.e. not covering things consistently (API-wide) >

[RFC v5 20/23] clockevents: purge ->min_delta_ns

The struct clock_event_device's ->min_delta_ns member isn't used anymore. Purge it. In __clockevents_update_bounds(), shortcut the ->min_delta_ticks => ->min_delta_ns => ->min_delta_ticks_adjusted calculation detour -- it had been made solely for the purpose of ensuring that

[RFC v5 14/23] clockevents: decouple ->max_delta_ns from ->max_delta_ticks

Before converting the given delta from ns to cycles by means of the mult/shift pair, clockevents_program_event() enforces it to be less or equal than ->max_delta_ns. Simplified, this reads as delta = min(delta, dev->max_delta_ns); clc = (delta * dev->mult) >> dev->shift; A device's

[RFC v5 17/23] clockevents: use ->min_delta_ticks_adjusted to program minimum delta

The use of a clockevent device's ->min_delta_ns in the event programming path hinders upcoming changes to the clockevent core making it NTP correction aware: both, ->mult and ->min_delta_ns would need to get updated as well as consumed atomically and we'd rather like to avoid any locking here. We

[RFC v5 17/23] clockevents: use ->min_delta_ticks_adjusted to program minimum delta

The use of a clockevent device's ->min_delta_ns in the event programming path hinders upcoming changes to the clockevent core making it NTP correction aware: both, ->mult and ->min_delta_ns would need to get updated as well as consumed atomically and we'd rather like to avoid any locking here. We

[RFC v5 21/23] clockevents: initial support for mono to raw time conversion

With NOHZ_FULL and one single well-isolated, CPU consumptive task, one would expect approximately one clockevent interrupt per second. However, on my Intel Haswell where the monotonic clock is the TSC monotonic clock and the clockevent device is the TSC deadline device, it turns out that every

[RFC v5 19/23] timer_list: print_tickdevice(): calculate ->min_delta_ns dynamically

print_tickdevice(), assembling the per-tick device sections in /proc/timer_list, is the last user of struct clock_event_device's ->min_delta_ns member. In order to make this one fully obsolete while retaining userspace ABI, calculate the displayed value of 'min_delta_ns' on the fly from

[RFC v5 21/23] clockevents: initial support for mono to raw time conversion

With NOHZ_FULL and one single well-isolated, CPU consumptive task, one would expect approximately one clockevent interrupt per second. However, on my Intel Haswell where the monotonic clock is the TSC monotonic clock and the clockevent device is the TSC deadline device, it turns out that every

[RFC v5 19/23] timer_list: print_tickdevice(): calculate ->min_delta_ns dynamically

print_tickdevice(), assembling the per-tick device sections in /proc/timer_list, is the last user of struct clock_event_device's ->min_delta_ns member. In order to make this one fully obsolete while retaining userspace ABI, calculate the displayed value of 'min_delta_ns' on the fly from

[RFC v5 18/23] clockevents: min delta increment: calculate min_delta_ns from ticks

The use of a clockevent device's ->min_delta_ns in the event programming path hinders upcoming changes to the clockevent core making it NTP correction aware: both, ->mult and ->min_delta_ns would need to get updated as well as consumed atomically and we'd rather like to avoid any locking here. We

[RFC v5 22/23] clockevents: make setting of ->mult and ->mult_adjusted atomic

In order to avoid races between setting a struct clock_event_device's ->mult_adjusted in clockevents_update_freq() and yet to be implemented updates triggered from the timekeeping core, the setting of ->mult and ->mult_adjusted should be made atomic. Protect the update in

[RFC v5 23/23] timekeeping: inform clockevents about freq adjustments

Upon adjustments of the monotonic clock's frequencies from the timekeeping core, the clockevents devices' ->mult_adjusted should be changed accordingly, too. Introduce clockevents_adjust_all_freqs() which traverses all registered clockevent devices and, if the CLOCK_EVT_FEAT_NO_ADJUST flag is not

[RFC v5 15/23] clockevents: do comparison of delta against minimum in terms of cycles

Before converting the given delta from ns to cycles by means of the mult/shift pair, clockevents_program_event() enforces it to be greater or equal than ->max_delta_ns. Simplified, this reads as delta = max(delta, dev->min_delta_ns); clc = (delta * dev->mult) >> dev->shift; Note that

[RFC v5 18/23] clockevents: min delta increment: calculate min_delta_ns from ticks

The use of a clockevent device's ->min_delta_ns in the event programming path hinders upcoming changes to the clockevent core making it NTP correction aware: both, ->mult and ->min_delta_ns would need to get updated as well as consumed atomically and we'd rather like to avoid any locking here. We

[RFC v5 22/23] clockevents: make setting of ->mult and ->mult_adjusted atomic

In order to avoid races between setting a struct clock_event_device's ->mult_adjusted in clockevents_update_freq() and yet to be implemented updates triggered from the timekeeping core, the setting of ->mult and ->mult_adjusted should be made atomic. Protect the update in

[RFC v5 23/23] timekeeping: inform clockevents about freq adjustments

Upon adjustments of the monotonic clock's frequencies from the timekeeping core, the clockevents devices' ->mult_adjusted should be changed accordingly, too. Introduce clockevents_adjust_all_freqs() which traverses all registered clockevent devices and, if the CLOCK_EVT_FEAT_NO_ADJUST flag is not

[RFC v5 15/23] clockevents: do comparison of delta against minimum in terms of cycles

Before converting the given delta from ns to cycles by means of the mult/shift pair, clockevents_program_event() enforces it to be greater or equal than ->max_delta_ns. Simplified, this reads as delta = max(delta, dev->min_delta_ns); clc = (delta * dev->mult) >> dev->shift; Note that

[RFC v5 12/23] many clockevent drivers: don't set ->min_delta_ns and ->max_delta_ns

Now that the clockevent core always initializes the ->*_delta_ns values from their ->_delta_ticks counterparts, there is no point in having the clockevent devices' drivers doing so as well. Don't initialize ->min_delta_ns and ->max_delta_ns from the clockevent devices' drivers. This patch was

[RFC v5 13/23] clockevents: introduce CLOCK_EVT_FEAT_NO_ADJUST flag

Upcoming changes to the clockevent core will make it adjusting a clockevent device's mult/shift pair in order to compensate for NTP corrections made by the timekeeping core. For certain devices this behaviour is unwanted. Introduce the CLOCK_EVT_FEAT_NO_ADJUST flag that, when being set, will

[RFC v5 12/23] many clockevent drivers: don't set ->min_delta_ns and ->max_delta_ns

Now that the clockevent core always initializes the ->*_delta_ns values from their ->_delta_ticks counterparts, there is no point in having the clockevent devices' drivers doing so as well. Don't initialize ->min_delta_ns and ->max_delta_ns from the clockevent devices' drivers. This patch was

[RFC v5 13/23] clockevents: introduce CLOCK_EVT_FEAT_NO_ADJUST flag

Upcoming changes to the clockevent core will make it adjusting a clockevent device's mult/shift pair in order to compensate for NTP corrections made by the timekeeping core. For certain devices this behaviour is unwanted. Introduce the CLOCK_EVT_FEAT_NO_ADJUST flag that, when being set, will

[RFC v5 02/23] clocksource: sh_tmu: compute rate before registration again

With the upcoming NTP correction related rate adjustments to be implemented in the clockevents core, the latter needs to get informed about every rate change of a clockevent device made after its registration. Currently, sh_tmu violates this requirement in that it registers its clockevent device

[RFC v5 09/23] arch/x86/platform/uv/uv_time: set ->min_delta_ticks and ->max_delta_ticks

With the yet to come introduction of NTP correction awareness to the clockevent core, drivers should report their valid ranges in units of cycles to the latter. Currently, the x86's uv rtc clockevent device is initialized as follows: clock_event_device_uv.min_delta_ns = NSEC_PER_SEC /

[RFC v5 07/23] many clockevent drivers: set ->min_delta_ticks and ->max_delta_ticks

The struct clock_event_device has got the ->min_delta_ns, ->max_delta_ns, ->min_delta_ticks and ->max_delta_ticks members for setting the bounds of valid deltas to be programmed. During operation, the clockevent core uses the ->*_delta_ns versions only. OTOH, the ->*_delta_ticks are currently

[RFC v5 10/23] arch/tile/kernel/time: set ->min_delta_ticks and ->max_delta_ticks

With the yet to come introduction of NTP correction awareness to the clockevent core, drivers should report their valid ranges in units of cycles to the latter. Currently, the tile's timer clockevent device is initialized as follows: evt->max_delta_ns = clockevent_delta2ns(MAX_TICK, evt); and

[RFC v5 02/23] clocksource: sh_tmu: compute rate before registration again

With the upcoming NTP correction related rate adjustments to be implemented in the clockevents core, the latter needs to get informed about every rate change of a clockevent device made after its registration. Currently, sh_tmu violates this requirement in that it registers its clockevent device

[RFC v5 09/23] arch/x86/platform/uv/uv_time: set ->min_delta_ticks and ->max_delta_ticks

With the yet to come introduction of NTP correction awareness to the clockevent core, drivers should report their valid ranges in units of cycles to the latter. Currently, the x86's uv rtc clockevent device is initialized as follows: clock_event_device_uv.min_delta_ns = NSEC_PER_SEC /

[RFC v5 07/23] many clockevent drivers: set ->min_delta_ticks and ->max_delta_ticks

The struct clock_event_device has got the ->min_delta_ns, ->max_delta_ns, ->min_delta_ticks and ->max_delta_ticks members for setting the bounds of valid deltas to be programmed. During operation, the clockevent core uses the ->*_delta_ns versions only. OTOH, the ->*_delta_ticks are currently

[RFC v5 10/23] arch/tile/kernel/time: set ->min_delta_ticks and ->max_delta_ticks

With the yet to come introduction of NTP correction awareness to the clockevent core, drivers should report their valid ranges in units of cycles to the latter. Currently, the tile's timer clockevent device is initialized as follows: evt->max_delta_ns = clockevent_delta2ns(MAX_TICK, evt); and

[RFC v5 01/23] clocksource: sh_cmt: compute rate before registration again

With the upcoming NTP correction related rate adjustments to be implemented in the clockevents core, the latter needs to get informed about every rate change of a clockevent device made after its registration. Currently, sh_cmt violates this requirement in that it registers its clockevent device

[RFC v5 00/23] adapt clockevents frequencies to mono clock

Goal: avoid programming ced devices too early for large deltas, for details, for details, c.f. the description of [21/23]. Previous v4 of this series can be found here: http://lkml.kernel.org/r/20160822233320.4548-1-nicsta...@gmail.com Raised concerns were 1.) There should be a flag

[RFC v5 01/23] clocksource: sh_cmt: compute rate before registration again

With the upcoming NTP correction related rate adjustments to be implemented in the clockevents core, the latter needs to get informed about every rate change of a clockevent device made after its registration. Currently, sh_cmt violates this requirement in that it registers its clockevent device

[RFC v5 00/23] adapt clockevents frequencies to mono clock

Goal: avoid programming ced devices too early for large deltas, for details, for details, c.f. the description of [21/23]. Previous v4 of this series can be found here: http://lkml.kernel.org/r/20160822233320.4548-1-nicsta...@gmail.com Raised concerns were 1.) There should be a flag

[RFC v5 11/23] clockevents: always initialize ->min_delta_ns and ->max_delta_ns

Now that all clockevent drivers set ->min_delta_ticks and ->max_delta_ticks independently of whether they use clockevents_config*() or not, the clockevent core can calculate ->min_delta_ns and ->max_delta_ns from these unconditionally. The goal is to prepare the clockevent core for introducing

[RFC v5 04/23] clocksource: em_sti: compute rate before registration

With the upcoming NTP correction related rate adjustments to be implemented in the clockevents core, the latter needs to get informed about every rate change of a clockevent device made after its registration. Currently, em_sti violates this requirement in that it registers its clockevent device

[RFC v5 11/23] clockevents: always initialize ->min_delta_ns and ->max_delta_ns

Now that all clockevent drivers set ->min_delta_ticks and ->max_delta_ticks independently of whether they use clockevents_config*() or not, the clockevent core can calculate ->min_delta_ns and ->max_delta_ns from these unconditionally. The goal is to prepare the clockevent core for introducing

[RFC v5 04/23] clocksource: em_sti: compute rate before registration

With the upcoming NTP correction related rate adjustments to be implemented in the clockevents core, the latter needs to get informed about every rate change of a clockevent device made after its registration. Currently, em_sti violates this requirement in that it registers its clockevent device

[RFC v5 03/23] clocksource: em_sti: split clock prepare and enable steps

Currently, the em_sti driver prepares and enables the needed clock in em_sti_enable(), potentially called through its clockevent device's ->set_state_oneshot(). However, the clk_prepare() step may sleep whereas tick_program_event() and thus, ->set_state_oneshot(), can be called in atomic context.

[RFC v5 03/23] clocksource: em_sti: split clock prepare and enable steps

Currently, the em_sti driver prepares and enables the needed clock in em_sti_enable(), potentially called through its clockevent device's ->set_state_oneshot(). However, the clk_prepare() step may sleep whereas tick_program_event() and thus, ->set_state_oneshot(), can be called in atomic context.

[RFC v5 05/23] clocksource: h8300_timer8: don't reset rate in ->set_state_oneshot()

With the upcoming NTP correction related rate adjustments to be implemented in the clockevents core, the latter needs to get informed about every rate change of a clockevent device made after its registration. Currently, h8300_timer8 violates this requirement in that it registers its clockevent

[RFC v5 06/23] clockevents: make clockevents_config() static

A clockevent device's rate should be configured before or at registration and changed afterwards through clockevents_update_freq() only. For the configuration at registration, we already have clockevents_config_and_register(). Right now, there are no clockevents_config() users outside of the

[RFC v5 05/23] clocksource: h8300_timer8: don't reset rate in ->set_state_oneshot()

With the upcoming NTP correction related rate adjustments to be implemented in the clockevents core, the latter needs to get informed about every rate change of a clockevent device made after its registration. Currently, h8300_timer8 violates this requirement in that it registers its clockevent

[RFC v5 06/23] clockevents: make clockevents_config() static

A clockevent device's rate should be configured before or at registration and changed afterwards through clockevents_update_freq() only. For the configuration at registration, we already have clockevents_config_and_register(). Right now, there are no clockevents_config() users outside of the

[RFC v5 08/23] arch/s390/kernel/time: set ->min_delta_ticks and ->max_delta_ticks

With the yet to come introduction of NTP correction awareness to the clockevent core, drivers should report their valid ranges in units of cycles to the latter. Currently, the s390's CPU timer clockevent device is initialized as follows: cd->min_delta_ns= 1; cd->max_delta_ns=

[RFC v5 08/23] arch/s390/kernel/time: set ->min_delta_ticks and ->max_delta_ticks

With the yet to come introduction of NTP correction awareness to the clockevent core, drivers should report their valid ranges in units of cycles to the latter. Currently, the s390's CPU timer clockevent device is initialized as follows: cd->min_delta_ns= 1; cd->max_delta_ns=

  1   2   3   4   5   6   7   >