Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

On 04/08/2016 02:29 AM, Luis R. Rodriguez wrote: On Thu, Apr 7, 2016 at 10:18 PM, Juergen Gross wrote: On 08/04/16 02:32, Luis R. Rodriguez wrote: On Thu, Apr 07, 2016 at 08:55:54AM -0400, Boris Ostrovsky wrote: On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote: We have 4

Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

On 04/08/2016 02:29 AM, Luis R. Rodriguez wrote: On Thu, Apr 7, 2016 at 10:18 PM, Juergen Gross wrote: On 08/04/16 02:32, Luis R. Rodriguez wrote: On Thu, Apr 07, 2016 at 08:55:54AM -0400, Boris Ostrovsky wrote: On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote: We have 4 types of x86

Re: [PATCH] Revert "Input: atmel_mxt_ts - disable interrupt for 50ms after reset"

On 2016-04-08 13:14, Tom Rini wrote: > On Fri, Apr 08, 2016 at 10:10:06AM +0100, Nick Dyer wrote: >> On 2016-04-07 23:52, Tom Rini wrote: >>> This reverts commit 885f3fb9fa1f9e185e8a4e905157087495734349 due to this >>> change breaking the touchpad on the Chromebook Pixel 2015 on resume from >>>

Re: [PATCH v2] x86: Calculate MHz using APERF/MPERF for cpuinfo and scaling_cur_freq

>For x86 processors with APERF/MPERF and TSC, return > meaningful and consistent MHz in /proc/cpuinfo and > /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq > >MHz is computed like so: > >MHz = base_MHz * delta_APERF / delta_MPERF > >or when delta_APERF is large, to prevent >64-bit overflow:

Re: [PATCH] Revert "Input: atmel_mxt_ts - disable interrupt for 50ms after reset"

On 2016-04-08 13:14, Tom Rini wrote: > On Fri, Apr 08, 2016 at 10:10:06AM +0100, Nick Dyer wrote: >> On 2016-04-07 23:52, Tom Rini wrote: >>> This reverts commit 885f3fb9fa1f9e185e8a4e905157087495734349 due to this >>> change breaking the touchpad on the Chromebook Pixel 2015 on resume from >>>

Re: [PATCH v2] x86: Calculate MHz using APERF/MPERF for cpuinfo and scaling_cur_freq

>For x86 processors with APERF/MPERF and TSC, return > meaningful and consistent MHz in /proc/cpuinfo and > /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq > >MHz is computed like so: > >MHz = base_MHz * delta_APERF / delta_MPERF > >or when delta_APERF is large, to prevent >64-bit overflow:

Re: [PATCH v3 04/16] arm64: dts: Add Hi6220 gpio configuration nodes

On Tue, Apr 5, 2016 at 3:27 PM, Guodong Xu wrote: > From: Zhong Kaihua > > Add Hi6220 gpio configuration nodes > > Signed-off-by: Zhong Kaihua > Signed-off-by: Kong Xinwei > I asked you to

Re: [PATCH v3 04/16] arm64: dts: Add Hi6220 gpio configuration nodes

On Tue, Apr 5, 2016 at 3:27 PM, Guodong Xu wrote: > From: Zhong Kaihua > > Add Hi6220 gpio configuration nodes > > Signed-off-by: Zhong Kaihua > Signed-off-by: Kong Xinwei > I asked you to remove this blank line. > Acked-by: Rob Herring > Signed-off-by: Wei Xu (...) > +++

Re: [PATCH] i2c: designware: do not disable adapter after transfer

Hi On 04/01/2016 05:47 AM, Lucas De Marchi wrote: From: Lucas De Marchi Disabling the adapter after each transfer is pretty bad for sensors and other devices doing small transfers at a high rate. It slows down the transfer rate a lot since each of them have to wait

Re: [PATCH v3 02/16] arm64: dts: add sp804 timer node for Hi6220

On Tue, Apr 5, 2016 at 3:27 PM, Guodong Xu wrote: > From: Leo Yan > > Add sp804 timer for hi6220, so it can be used as broadcast timer. > > Signed-off-by: Leo Yan Reviewed-by: Linus Walleij Yours, Linus

Re: [PATCH] i2c: designware: do not disable adapter after transfer

Hi On 04/01/2016 05:47 AM, Lucas De Marchi wrote: From: Lucas De Marchi Disabling the adapter after each transfer is pretty bad for sensors and other devices doing small transfers at a high rate. It slows down the transfer rate a lot since each of them have to wait the adapter to be enabled

Re: [PATCH v3 02/16] arm64: dts: add sp804 timer node for Hi6220

On Tue, Apr 5, 2016 at 3:27 PM, Guodong Xu wrote: > From: Leo Yan > > Add sp804 timer for hi6220, so it can be used as broadcast timer. > > Signed-off-by: Leo Yan Reviewed-by: Linus Walleij Yours, Linus Walleij

Re: [PATCH] Revert "Input: atmel_mxt_ts - disable interrupt for 50ms after reset"

On Fri, Apr 08, 2016 at 10:10:06AM +0100, Nick Dyer wrote: > On 2016-04-07 23:52, Tom Rini wrote: > > This reverts commit 885f3fb9fa1f9e185e8a4e905157087495734349 due to this > > change breaking the touchpad on the Chromebook Pixel 2015 on resume from > > sleep or warm resets. > > > > Cc: Olof

Re: [PATCH] Revert "Input: atmel_mxt_ts - disable interrupt for 50ms after reset"

On Fri, Apr 08, 2016 at 10:10:06AM +0100, Nick Dyer wrote: > On 2016-04-07 23:52, Tom Rini wrote: > > This reverts commit 885f3fb9fa1f9e185e8a4e905157087495734349 due to this > > change breaking the touchpad on the Chromebook Pixel 2015 on resume from > > sleep or warm resets. > > > > Cc: Olof

Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

On Fri, 2016-04-08 at 12:30 +0200, Sebastian Andrzej Siewior wrote: > On 04/07/2016 09:04 PM, Mike Galbraith wrote: > > > just to be clear: The patch I attached did _not_ work for you. > > > > Sorry, I didn't test. Marathon stress test session convinced me that > > the lock added by -rt

Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

On Fri, 2016-04-08 at 12:30 +0200, Sebastian Andrzej Siewior wrote: > On 04/07/2016 09:04 PM, Mike Galbraith wrote: > > > just to be clear: The patch I attached did _not_ work for you. > > > > Sorry, I didn't test. Marathon stress test session convinced me that > > the lock added by -rt

Re: [PATCH 06/10] watchdog: ebc-c384_wdt: Utilize the ISA bus driver

On Thu, Apr 07, 2016 at 05:35:35PM -0700, Guenter Roeck wrote: >I am a bit concerend that the newly introduced ISA_BUS is not automatically >enabled. Effectively this means that all drivers depending on it will >be disabled until someone enables ISA_BUS in the distribution. > >Is this a concern

Re: [PATCH 06/10] watchdog: ebc-c384_wdt: Utilize the ISA bus driver

On Thu, Apr 07, 2016 at 05:35:35PM -0700, Guenter Roeck wrote: >I am a bit concerend that the newly introduced ISA_BUS is not automatically >enabled. Effectively this means that all drivers depending on it will >be disabled until someone enables ISA_BUS in the distribution. > >Is this a concern

Re: [PATCH] stm class: correct masterID range in setting via sysfs

Chunyan Zhang writes: > The type of masterID is defined as 'unsigned int', theoretically one > can set masterID with a number larger than 'INT_MAX' as long as > 'stm_data::sw_end' is larger than 'INT_MAX'. > > Also, 'stm_data::start' and 'stm_data::end' is initialized

Re: [PATCH] stm class: correct masterID range in setting via sysfs

Chunyan Zhang writes: > The type of masterID is defined as 'unsigned int', theoretically one > can set masterID with a number larger than 'INT_MAX' as long as > 'stm_data::sw_end' is larger than 'INT_MAX'. > > Also, 'stm_data::start' and 'stm_data::end' is initialized in respective > drivers

Re: [PATCH v10 1/4] gadget: Introduce the usb charger framework

On 8 April 2016 at 19:27, Jun Li wrote: > > >> -Original Message- >> From: Baolin Wang [mailto:baolin.w...@linaro.org] >> Sent: Friday, April 08, 2016 7:00 PM >> To: Jun Li >> Cc: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org; >>

Re: [PATCH v10 1/4] gadget: Introduce the usb charger framework

On 8 April 2016 at 19:27, Jun Li wrote: > > >> -Original Message- >> From: Baolin Wang [mailto:baolin.w...@linaro.org] >> Sent: Friday, April 08, 2016 7:00 PM >> To: Jun Li >> Cc: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org; >> dbarysh...@gmail.com; dw...@infradead.org;

Re: [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skip regular OOM killer path

_MEMDIE for all tasks queued for oom_reaper" will select the same > thread again. true, will update my patch. > Though I think we should not allow the OOM killer to select the same > thread again. > > > > > Why don't you call try_oom_reaper() from the shortcuts in > &

Re: [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skip regular OOM killer path

_MEMDIE for all tasks queued for oom_reaper" will select the same > thread again. true, will update my patch. > Though I think we should not allow the OOM killer to select the same > thread again. > > > > > Why don't you call try_oom_reaper() from the shortcuts in > &

RE: [PATCH v10 1/4] gadget: Introduce the usb charger framework

> -Original Message- > From: Baolin Wang [mailto:baolin.w...@linaro.org] > Sent: Friday, April 08, 2016 7:00 PM > To: Jun Li > Cc: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org; > dbarysh...@gmail.com; dw...@infradead.org; peter.c...@freescale.com; >

RE: [PATCH v10 1/4] gadget: Introduce the usb charger framework

> -Original Message- > From: Baolin Wang [mailto:baolin.w...@linaro.org] > Sent: Friday, April 08, 2016 7:00 PM > To: Jun Li > Cc: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org; > dbarysh...@gmail.com; dw...@infradead.org; peter.c...@freescale.com; >

Re: [PATCH 3/3] mm, oom_reaper: clear TIF_MEMDIE for all tasks queued for oom_reaper

On Thu 07-04-16 20:55:34, Tetsuo Handa wrote: > Michal Hocko wrote: > > The first obvious one is when the oom victim clears its mm and gets > > stuck later on. oom_reaper would back of on find_lock_task_mm returning > > NULL. We can safely try to clear TIF_MEMDIE in this case because such a > >

Re: [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skip regular OOM killer path

On Thu 07-04-16 20:38:43, Tetsuo Handa wrote: > Michal Hocko wrote: > > @@ -563,6 +582,53 @@ static void wake_oom_reaper(struct task_struct *tsk) > > wake_up(_reaper_wait); > > } > > > > +/* Check if we can reap the given task. This has to be called with stable > > + * tsk->mm > > + */ > >

Re: [PATCH 3/3] mm, oom_reaper: clear TIF_MEMDIE for all tasks queued for oom_reaper

On Thu 07-04-16 20:55:34, Tetsuo Handa wrote: > Michal Hocko wrote: > > The first obvious one is when the oom victim clears its mm and gets > > stuck later on. oom_reaper would back of on find_lock_task_mm returning > > NULL. We can safely try to clear TIF_MEMDIE in this case because such a > >

Re: [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skip regular OOM killer path

On Thu 07-04-16 20:38:43, Tetsuo Handa wrote: > Michal Hocko wrote: > > @@ -563,6 +582,53 @@ static void wake_oom_reaper(struct task_struct *tsk) > > wake_up(_reaper_wait); > > } > > > > +/* Check if we can reap the given task. This has to be called with stable > > + * tsk->mm > > + */ > >

Re: [PATCH] sched/fair: Optimize sum computation with a lookup table

On Fri, Apr 08, 2016 at 10:07:20AM +0800, Yuyang Du wrote: > __compute_runnable_contrib() uses a loop to compute sum, whereas a > table loopup can do it faster in a constant time. > > Signed-off-by: Yuyang Du > --- > kernel/sched/fair.c | 20 > 1 file

Re: [PATCH] sched/fair: Optimize sum computation with a lookup table

On Fri, Apr 08, 2016 at 10:07:20AM +0800, Yuyang Du wrote: > __compute_runnable_contrib() uses a loop to compute sum, whereas a > table loopup can do it faster in a constant time. > > Signed-off-by: Yuyang Du > --- > kernel/sched/fair.c | 20 > 1 file changed, 12

RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

Hi, > From: Roger Quadros > Sent: Thursday, April 07, 2016 8:45 PM > > Hi, > > On 07/04/16 11:52, Yoshihiro Shimoda wrote: > > Hi, > > > >> From: Roger Quadros > >> Sent: Tuesday, April 05, 2016 11:05 PM < snip > > > diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c > >

RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

Hi, > From: Roger Quadros > Sent: Thursday, April 07, 2016 8:45 PM > > Hi, > > On 07/04/16 11:52, Yoshihiro Shimoda wrote: > > Hi, > > > >> From: Roger Quadros > >> Sent: Tuesday, April 05, 2016 11:05 PM < snip > > > diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c > >

Re: [PATCH v2 8/8] scsi: ufs: connect to RPMB subsystem

On 4/7/2016 10:15 PM, Winkler, Tomas wrote: > On Wed, 2016-04-06 at 09:51 +0100, Joao Pinto wrote: >> Hi! >> >> On 4/4/2016 12:11 PM, Tomas Winkler wrote: >>> Register UFS RPMB LUN with the RPMB subsystem and provide >>> implementation for the RPMB access operations. RPMB partition is >>> accessed

Re: [PATCH v2 8/8] scsi: ufs: connect to RPMB subsystem

On 4/7/2016 10:15 PM, Winkler, Tomas wrote: > On Wed, 2016-04-06 at 09:51 +0100, Joao Pinto wrote: >> Hi! >> >> On 4/4/2016 12:11 PM, Tomas Winkler wrote: >>> Register UFS RPMB LUN with the RPMB subsystem and provide >>> implementation for the RPMB access operations. RPMB partition is >>> accessed

Re: [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skip regular OOM killer path

if (tsk == oom_reaper_list || tsk->oom_reaper_list) return; test in wake_oom_reaper() if "[PATCH 3/3] mm, oom_reaper: clear TIF_MEMDIE for all tasks queued for oom_reaper" will select the same thread again. Though I think we should not allow the OOM killer to select the same t

Re: [PATCH 2/3] oom, oom_reaper: Try to reap tasks which skip regular OOM killer path

if (tsk == oom_reaper_list || tsk->oom_reaper_list) return; test in wake_oom_reaper() if "[PATCH 3/3] mm, oom_reaper: clear TIF_MEMDIE for all tasks queued for oom_reaper" will select the same thread again. Though I think we should not allow the OOM killer to select the same t

Re: [PATCH v2 8/8] scsi: ufs: connect to RPMB subsystem

Hi, On 4/7/2016 10:15 PM, Winkler, Tomas wrote: > On Wed, 2016-04-06 at 09:51 +0100, Joao Pinto wrote: >> Hi! >> >> On 4/4/2016 12:11 PM, Tomas Winkler wrote: >>> Register UFS RPMB LUN with the RPMB subsystem and provide >>> implementation for the RPMB access operations. RPMB partition is >>>

Re: [PATCH v2 8/8] scsi: ufs: connect to RPMB subsystem

Hi, On 4/7/2016 10:15 PM, Winkler, Tomas wrote: > On Wed, 2016-04-06 at 09:51 +0100, Joao Pinto wrote: >> Hi! >> >> On 4/4/2016 12:11 PM, Tomas Winkler wrote: >>> Register UFS RPMB LUN with the RPMB subsystem and provide >>> implementation for the RPMB access operations. RPMB partition is >>>

Re: [PATCH v3 12/18] dt-bindings: Add PLX Technology OXNAS pinctrl and gpio bindings

On Fri, Apr 1, 2016 at 5:48 PM, Neil Armstrong wrote: > On 04/01/2016 05:19 PM, Rob Herring wrote: >> On Fri, Apr 1, 2016 at 9:30 AM, Neil Armstrong >> wrote: >>> What should I use ? >> >> Maybe gpio-ranges as you asked. Not really sure as

Re: [PATCH v3 12/18] dt-bindings: Add PLX Technology OXNAS pinctrl and gpio bindings

On Thu, Mar 31, 2016 at 3:36 PM, Rob Herring wrote: > Looking at one example, it appears to be redundant already. > nomadik-gpio-chips property already gives you the index. The index of > the phandles is the bank numbering. PIC32 could do the same. nomadik-gpio-chips is a

Re: [PATCH v2] clk: let clk_disable() return immediately if clk is NULL or error

2016-04-08 19:06 GMT+09:00 Ralf Baechle : > On Thu, Apr 07, 2016 at 05:33:28PM -0700, Stephen Boyd wrote: > >> On 04/05, Masahiro Yamada wrote: >> > The clk_disable() in the common clock framework (drivers/clk/clk.c) >> > returns immediately if a given clk is NULL or an error

Re: [PATCH v3 12/18] dt-bindings: Add PLX Technology OXNAS pinctrl and gpio bindings

On Fri, Apr 1, 2016 at 5:48 PM, Neil Armstrong wrote: > On 04/01/2016 05:19 PM, Rob Herring wrote: >> On Fri, Apr 1, 2016 at 9:30 AM, Neil Armstrong >> wrote: >>> What should I use ? >> >> Maybe gpio-ranges as you asked. Not really sure as I haven't used it. > > If I use gpio-ranges I can

Re: [PATCH v3 12/18] dt-bindings: Add PLX Technology OXNAS pinctrl and gpio bindings

On Thu, Mar 31, 2016 at 3:36 PM, Rob Herring wrote: > Looking at one example, it appears to be redundant already. > nomadik-gpio-chips property already gives you the index. The index of > the phandles is the bank numbering. PIC32 could do the same. nomadik-gpio-chips is a property on the pin

Re: [PATCH v2] clk: let clk_disable() return immediately if clk is NULL or error

2016-04-08 19:06 GMT+09:00 Ralf Baechle : > On Thu, Apr 07, 2016 at 05:33:28PM -0700, Stephen Boyd wrote: > >> On 04/05, Masahiro Yamada wrote: >> > The clk_disable() in the common clock framework (drivers/clk/clk.c) >> > returns immediately if a given clk is NULL or an error pointer. It >> >

[PATCH V2] mtd: nand: pasemi: switch to pr_* functions

1) Use pr_fmt to keep messages consistent 2) Don't warn if kzalloc fails as it dumps stack on its own 3) Use %pR format for displaying whole resource to avoid: warning: format ‘%08llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘resource_size_t’ Signed-off-by: Rafał Miłecki

[PATCH V2] mtd: nand: pasemi: switch to pr_* functions

1) Use pr_fmt to keep messages consistent 2) Don't warn if kzalloc fails as it dumps stack on its own 3) Use %pR format for displaying whole resource to avoid: warning: format ‘%08llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘resource_size_t’ Signed-off-by: Rafał Miłecki

sched: How does the scheduler determine which CPU core gets the job?

Short summary: == Investigating an isuue where parallel tasks are spread differently over the available CPU cores, depending if the machine was cold booted from power off or warm booted by init 6. On cold boot the parallel processes were spread as expected so that with "N" cores and

sched: How does the scheduler determine which CPU core gets the job?

Short summary: == Investigating an isuue where parallel tasks are spread differently over the available CPU cores, depending if the machine was cold booted from power off or warm booted by init 6. On cold boot the parallel processes were spread as expected so that with "N" cores and

Ищете офис побольше?

Добрый день! Пожалуйста сообщите - вопрос аренды офиса еще актуален для Вас? Написала Вам - так как у нас сейчас освободились топовые площади под Ваш бизнес: несколько небольших помещений в ЦАО Москвы, есть и под торговлю и под офисы (даже на первом этаже) рядом метро Комсомольская. А также у

Ищете офис побольше?

Добрый день! Пожалуйста сообщите - вопрос аренды офиса еще актуален для Вас? Написала Вам - так как у нас сейчас освободились топовые площади под Ваш бизнес: несколько небольших помещений в ЦАО Москвы, есть и под торговлю и под офисы (даже на первом этаже) рядом метро Комсомольская. А также у

Re: [RFC PATCH 0/3] restartable sequences v2: fast user-space percpu critical sections

On Thu, Apr 07, 2016 at 03:05:26PM -0700, Andy Lutomirski wrote: > It doesn't, which is what I like about my variant. If the thread > accesses the protected data structure, though, it should bump the > sequence count, which will cause the first thread to about when it > gets scheduled in. Nope

Re: [RFC PATCH 0/3] restartable sequences v2: fast user-space percpu critical sections

On Thu, Apr 07, 2016 at 03:05:26PM -0700, Andy Lutomirski wrote: > It doesn't, which is what I like about my variant. If the thread > accesses the protected data structure, though, it should bump the > sequence count, which will cause the first thread to about when it > gets scheduled in. Nope

Re: [PATCH v2] pinctrl: mediatek: correct debounce time unit in mtk_gpio_set_debounce

On Sat, Apr 2, 2016 at 2:57 PM, Yingjoe Chen wrote: > The debounce time unit for gpio_chip.set_debounce is us but > mtk_gpio_set_debounce regard it as ms. > Fix this by correct debounce time array dbnc_arr so it can find correct > debounce setting. Debounce time for

Re: [PATCH v2] pinctrl: mediatek: correct debounce time unit in mtk_gpio_set_debounce

On Sat, Apr 2, 2016 at 2:57 PM, Yingjoe Chen wrote: > The debounce time unit for gpio_chip.set_debounce is us but > mtk_gpio_set_debounce regard it as ms. > Fix this by correct debounce time array dbnc_arr so it can find correct > debounce setting. Debounce time for first debounce setting is

Re: [PATCH v10 1/4] gadget: Introduce the usb charger framework

Hi Jun, >> >> +/* >> >> + * usb_charger_detect_type() - detect the charger type manually. >> >> + * @uchger - usb charger device >> >> + * >> >> + * Note: You should ensure you need to detect the charger type >> >> +manually on your >> >> + * platform. >> >> + * You should call it at the right

Re: [PATCH v10 1/4] gadget: Introduce the usb charger framework

Hi Jun, >> >> +/* >> >> + * usb_charger_detect_type() - detect the charger type manually. >> >> + * @uchger - usb charger device >> >> + * >> >> + * Note: You should ensure you need to detect the charger type >> >> +manually on your >> >> + * platform. >> >> + * You should call it at the right

[PATCH] mtd: nand: nuc900: allow compiling with COMPILE_TEST

This driver doesn't seem to have any compile-time arch dependencies. I was able to compile it on CONFIG_MIPS and CONFIG_ARM. Signed-off-by: Rafał Miłecki --- drivers/mtd/nand/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/Kconfig

[PATCH] mtd: nand: nuc900: allow compiling with COMPILE_TEST

This driver doesn't seem to have any compile-time arch dependencies. I was able to compile it on CONFIG_MIPS and CONFIG_ARM. Signed-off-by: Rafał Miłecki --- drivers/mtd/nand/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/Kconfig

Re: [PATCH] sched/fair: Optimize sum computation with a lookup table

On Fri, Apr 08, 2016 at 03:31:41AM -0700, Joe Perches wrote: > On Fri, 2016-04-08 at 10:07 +0800, Yuyang Du wrote: > > __compute_runnable_contrib() uses a loop to compute sum, whereas a > > table lookup can do it faster in a constant time. > > Perhaps this becomes rather fragile code overly

Re: [PATCH 1/2] drm/rockchip: vop: Do check if an update is pending during disable

On 8 April 2016 at 03:07, Mark yao wrote: > On 2016年04月06日 18:14, Tomeu Vizoso wrote: > > When a plane is being disabled but it's still enabled, do check if the > previous update has been completed by reading yrgb_mst back. > > Otherwise, pending pageflips would remain

Re: [PATCH] sched/fair: Optimize sum computation with a lookup table

On Fri, Apr 08, 2016 at 03:31:41AM -0700, Joe Perches wrote: > On Fri, 2016-04-08 at 10:07 +0800, Yuyang Du wrote: > > __compute_runnable_contrib() uses a loop to compute sum, whereas a > > table lookup can do it faster in a constant time. > > Perhaps this becomes rather fragile code overly

Re: [PATCH 1/2] drm/rockchip: vop: Do check if an update is pending during disable

On 8 April 2016 at 03:07, Mark yao wrote: > On 2016年04月06日 18:14, Tomeu Vizoso wrote: > > When a plane is being disabled but it's still enabled, do check if the > previous update has been completed by reading yrgb_mst back. > > Otherwise, pending pageflips would remain pending after a CRTC is >

Re: [PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks

On Thu, 2016-04-07 at 16:21 -0700, Stephen Boyd wrote: > On 04/06, Sjoerd Simons wrote: > > > > On Wed, 2016-04-06 at 15:11 +0200, Geert Uytterhoeven wrote: > > > > > > CC Mike, Stephen, linux-clk (this time with the new Mike) > > > > > > On Wed, Apr 6, 2016 at 2:52 PM, Sjoerd Simons > > >

Re: [PATCH] ARM: dts: r8a7791: Don't disable referenced optional clocks

On Thu, 2016-04-07 at 16:21 -0700, Stephen Boyd wrote: > On 04/06, Sjoerd Simons wrote: > > > > On Wed, 2016-04-06 at 15:11 +0200, Geert Uytterhoeven wrote: > > > > > > CC Mike, Stephen, linux-clk (this time with the new Mike) > > > > > > On Wed, Apr 6, 2016 at 2:52 PM, Sjoerd Simons > > >

Re: [PATCH] mtd: nand: pasemi: switch to pr_* functions

Hi Rafał, [auto build test WARNING on mtd/master] [also build test WARNING on v4.6-rc2 next-20160408] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/mtd-nand-pasemi-switch-to-pr_

Re: [PATCH] mtd: nand: pasemi: switch to pr_* functions

Hi Rafał, [auto build test WARNING on mtd/master] [also build test WARNING on v4.6-rc2 next-20160408] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/mtd-nand-pasemi-switch-to-pr_

Re: [PATCH] mtd: nand: pasemi: switch to pr_* functions

On Fri, 2016-04-08 at 12:33 +0200, Rafał Miłecki wrote: > This patch also replaces %08llx with %08zx for printing resource start > address. Old format was triggering: > warning: format ‘%08llx’ expects type ‘long long unsigned int’, but argument > 2 has type ‘resource_size_t’ trivia: > diff

Re: [PATCH] mtd: nand: pasemi: switch to pr_* functions

On Fri, 2016-04-08 at 12:33 +0200, Rafał Miłecki wrote: > This patch also replaces %08llx with %08zx for printing resource start > address. Old format was triggering: > warning: format ‘%08llx’ expects type ‘long long unsigned int’, but argument > 2 has type ‘resource_size_t’ trivia: > diff

Re: [PATCH] KVM: new maintainer on the block

On 04/07/2016 05:21 PM, Paolo Bonzini wrote: > Avi has kept Gleb busy enough, and Radim has been helping me > for a while, so let's "reward" him with an entry in > MAINTAINERS. > > Acked-by: Gleb Natapov > Cc: Radim Krčmář > --- > Radim, please commit

Re: [PATCH 3/3] sched: Optimize !CONFIG_NO_HZ_COMMON cpu load updates

On Fri, Apr 08, 2016 at 03:07:13AM +0200, Frederic Weisbecker wrote: > index 4c522a7..59a2821 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -7327,8 +7327,9 @@ void __init sched_init(void) > > for (j = 0; j < CPU_LOAD_IDX_MAX; j++) >

Re: [PATCH] KVM: new maintainer on the block

On 04/07/2016 05:21 PM, Paolo Bonzini wrote: > Avi has kept Gleb busy enough, and Radim has been helping me > for a while, so let's "reward" him with an entry in > MAINTAINERS. > > Acked-by: Gleb Natapov > Cc: Radim Krčmář > --- > Radim, please commit this yourself to kvm/master and >

Re: [PATCH 3/3] sched: Optimize !CONFIG_NO_HZ_COMMON cpu load updates

On Fri, Apr 08, 2016 at 03:07:13AM +0200, Frederic Weisbecker wrote: > index 4c522a7..59a2821 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -7327,8 +7327,9 @@ void __init sched_init(void) > > for (j = 0; j < CPU_LOAD_IDX_MAX; j++) >

Относительно вакансии на сайте

Здравствуйте! Увидела Вашу вакансию, мы смогли бы подобрать Вам несколько кандидатов. Сообщите пожалуйста - актуально ли это сейчас для Вас? И готовы ли Вы работать с нами как с кадровым агентством? У нас - реально очень низкая комиссия. Мы Проводим самостоятельное тестирование кандидатов -

Относительно вакансии на сайте

Здравствуйте! Увидела Вашу вакансию, мы смогли бы подобрать Вам несколько кандидатов. Сообщите пожалуйста - актуально ли это сейчас для Вас? И готовы ли Вы работать с нами как с кадровым агентством? У нас - реально очень низкая комиссия. Мы Проводим самостоятельное тестирование кандидатов -

Re: [PATCH] irqchip/mbigen: Display message of MBIGEN domain created

On 08/04/16 11:33, Kefeng Wang wrote: > > > On 2016/4/8 16:53, Marc Zyngier wrote: >> On Fri, 8 Apr 2016 16:26:21 +0800 >> Kefeng Wang wrote: > Overall, this doesn't look like a critical patch to me. I think Ma Jun is working on separate series reworking

Re: [PATCH] irqchip/mbigen: Display message of MBIGEN domain created

On 08/04/16 11:33, Kefeng Wang wrote: > > > On 2016/4/8 16:53, Marc Zyngier wrote: >> On Fri, 8 Apr 2016 16:26:21 +0800 >> Kefeng Wang wrote: > Overall, this doesn't look like a critical patch to me. I think Ma Jun is working on separate series reworking the way the mgigen is getting

Re: [PATCH] sched/fair: Optimize sum computation with a lookup table

On Fri, Apr 08, 2016 at 12:44:32PM +0200, Peter Zijlstra wrote: > On Fri, Apr 08, 2016 at 10:07:20AM +0800, Yuyang Du wrote: > > __compute_runnable_contrib() uses a loop to compute sum, whereas a > > table loopup can do it faster in a constant time. > > > - /* Compute \Sum k^n combining

Re: [PATCH] sched/fair: Optimize sum computation with a lookup table

On Fri, Apr 08, 2016 at 12:44:32PM +0200, Peter Zijlstra wrote: > On Fri, Apr 08, 2016 at 10:07:20AM +0800, Yuyang Du wrote: > > __compute_runnable_contrib() uses a loop to compute sum, whereas a > > table loopup can do it faster in a constant time. > > > - /* Compute \Sum k^n combining

Re: [PATCH] sched/fair: Optimize sum computation with a lookup table

On Fri, Apr 08, 2016 at 10:07:20AM +0800, Yuyang Du wrote: > __compute_runnable_contrib() uses a loop to compute sum, whereas a > table loopup can do it faster in a constant time. > - /* Compute \Sum k^n combining precomputed values for k^i, \Sum k^j */ > - do { > - contrib /=

Re: [PATCH] sched/fair: Optimize sum computation with a lookup table

On Fri, Apr 08, 2016 at 10:07:20AM +0800, Yuyang Du wrote: > __compute_runnable_contrib() uses a loop to compute sum, whereas a > table loopup can do it faster in a constant time. > - /* Compute \Sum k^n combining precomputed values for k^i, \Sum k^j */ > - do { > - contrib /=

Re: [PATCH v3 0/7] x86: Pile o' FS/GS changes

On Thu, Apr 07, 2016 at 05:31:43PM -0700, Andy Lutomirski wrote: > Hi all- > > This whole mess is intended for x86/urgent. It fixes several bugs. > > It's probably a tiny performance regression on some workloads on > Intel CPUs. It's probably varies between a less tiny regression and > a small

Re: [PATCH v3 0/7] x86: Pile o' FS/GS changes

On Thu, Apr 07, 2016 at 05:31:43PM -0700, Andy Lutomirski wrote: > Hi all- > > This whole mess is intended for x86/urgent. It fixes several bugs. > > It's probably a tiny performance regression on some workloads on > Intel CPUs. It's probably varies between a less tiny regression and > a small

Re: [PATCH v3 0/7] x86: Pile o' FS/GS changes

On Thu, Apr 07, 2016 at 05:31:43PM -0700, Andy Lutomirski wrote: > Hi all- > > This whole mess is intended for x86/urgent. It fixes several bugs. > > It's probably a tiny performance regression on some workloads on > Intel CPUs. It's probably varies between a less tiny regression and > a small

Re: [PATCH v3 0/7] x86: Pile o' FS/GS changes

On Thu, Apr 07, 2016 at 05:31:43PM -0700, Andy Lutomirski wrote: > Hi all- > > This whole mess is intended for x86/urgent. It fixes several bugs. > > It's probably a tiny performance regression on some workloads on > Intel CPUs. It's probably varies between a less tiny regression and > a small

Re: [PATCH] x86/vdso: Remove direct HPET access through the vDSO

On Thu, Apr 07, 2016 at 05:16:59PM -0700, Andy Lutomirski wrote: > Allowing user code to map the HPET is problematic. HPET > implementations are notoriously buggy, and there are probably many > machines on which even MMIO reads from bogus HPET addresses are > problematic. > > We have a report

Re: [PATCH] x86/vdso: Remove direct HPET access through the vDSO

On Thu, Apr 07, 2016 at 05:16:59PM -0700, Andy Lutomirski wrote: > Allowing user code to map the HPET is problematic. HPET > implementations are notoriously buggy, and there are probably many > machines on which even MMIO reads from bogus HPET addresses are > problematic. > > We have a report

Re: [PATCH] irqchip/mbigen: Display message of MBIGEN domain created

On 2016/4/8 16:53, Marc Zyngier wrote: > On Fri, 8 Apr 2016 16:26:21 +0800 > Kefeng Wang wrote: >>> Overall, this doesn't look like a critical patch to me. I think Ma Jun >>> is working on separate series reworking the way the mgigen is getting >>> probed, so I'd

[PATCH] sched/rt/deadline: Share cpumask between rt and deadline for SMP scheduling

Rt and deadline use their separate percpu mask to do SMP scheduling. All the operations related to the mask are under the protection of some spin_lock_irqsave(), hence we can safely use a shared one. The patch introduced "sched_pp_shared_mask"(pp means Push/Pull which are main users of the mask),

Re: [PATCH] irqchip/mbigen: Display message of MBIGEN domain created

On 2016/4/8 16:53, Marc Zyngier wrote: > On Fri, 8 Apr 2016 16:26:21 +0800 > Kefeng Wang wrote: >>> Overall, this doesn't look like a critical patch to me. I think Ma Jun >>> is working on separate series reworking the way the mgigen is getting >>> probed, so I'd advise you to work with him in

[PATCH] sched/rt/deadline: Share cpumask between rt and deadline for SMP scheduling

Rt and deadline use their separate percpu mask to do SMP scheduling. All the operations related to the mask are under the protection of some spin_lock_irqsave(), hence we can safely use a shared one. The patch introduced "sched_pp_shared_mask"(pp means Push/Pull which are main users of the mask),

[PATCH] mtd: nand: pasemi: switch to pr_* functions

This patch also replaces %08llx with %08zx for printing resource start address. Old format was triggering: warning: format ‘%08llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘resource_size_t’ Signed-off-by: Rafał Miłecki --- drivers/mtd/nand/pasemi_nand.c

[PATCH] mtd: nand: pasemi: switch to pr_* functions

This patch also replaces %08llx with %08zx for printing resource start address. Old format was triggering: warning: format ‘%08llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘resource_size_t’ Signed-off-by: Rafał Miłecki --- drivers/mtd/nand/pasemi_nand.c | 9 - 1

Re: [PATCH] sched/fair: Optimize sum computation with a lookup table

On Fri, 2016-04-08 at 10:07 +0800, Yuyang Du wrote: > __compute_runnable_contrib() uses a loop to compute sum, whereas a > table lookup can do it faster in a constant time. Perhaps this becomes rather fragile code overly dependent on the current #define values of LOAD_AVG_MAX_N and

Re: [PATCH] sched/fair: Optimize sum computation with a lookup table

On Fri, 2016-04-08 at 10:07 +0800, Yuyang Du wrote: > __compute_runnable_contrib() uses a loop to compute sum, whereas a > table lookup can do it faster in a constant time. Perhaps this becomes rather fragile code overly dependent on the current #define values of LOAD_AVG_MAX_N and

Re: [RFC v5 7/7] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

Hi Eric, On 2016/4/8 17:10, Eric Auger wrote: Hi Yongji, On 04/08/2016 10:14 AM, Yongji Xie wrote: Hi Eric, On 2016/4/7 22:23, Eric Auger wrote: Hi Yongji, On 04/07/2016 01:38 PM, Yongji Xie wrote: On 2016/4/6 22:45, Alex Williamson wrote: On Tue, 5 Apr 2016 21:46:44 +0800 Yongji Xie

Re: [RFC v5 7/7] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

Hi Eric, On 2016/4/8 17:10, Eric Auger wrote: Hi Yongji, On 04/08/2016 10:14 AM, Yongji Xie wrote: Hi Eric, On 2016/4/7 22:23, Eric Auger wrote: Hi Yongji, On 04/07/2016 01:38 PM, Yongji Xie wrote: On 2016/4/6 22:45, Alex Williamson wrote: On Tue, 5 Apr 2016 21:46:44 +0800 Yongji Xie

Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

On 04/07/2016 09:04 PM, Mike Galbraith wrote: >> just to be clear: The patch I attached did _not_ work for you. > > Sorry, I didn't test. Marathon stress test session convinced me that > the lock added by -rt absolutely had to die. Okay. And the patch did that. I removed the lock. >>> If that

Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

On 04/07/2016 09:04 PM, Mike Galbraith wrote: >> just to be clear: The patch I attached did _not_ work for you. > > Sorry, I didn't test. Marathon stress test session convinced me that > the lock added by -rt absolutely had to die. Okay. And the patch did that. I removed the lock. >>> If that

<    4   5   6   7   8   9   10   11   12   >