Re: [PATCH] gpio: Do not accept gpio chip additions before gpiolib initialization

On Wed, Mar 30, 2016 at 6:16 PM, Guenter Roeck wrote: > On 03/30/2016 01:37 AM, Alexandre Courbot wrote: >> >> On Wed, Mar 30, 2016 at 3:20 AM, Guenter Roeck wrote: >>> >>> Since commit ff2b13592299 ("gpio: make the gpiochip a real device"), >>> attempts

Re: [PATCH] net: mvneta: explicitly disable BM on 64bit platform

Hi Gregory, On Wed, 30 Mar 2016 17:11:41 +0200 Gregory CLEMENT wrote: > Hi Jisheng, > > On mer., mars 30 2016, Jisheng Zhang wrote: > > > The mvneta BM can't work on 64bit platform, as the BM hardware expects > > buf virtual address to be placed in the first four bytes

Re: [PATCH] gpio: Do not accept gpio chip additions before gpiolib initialization

On Wed, Mar 30, 2016 at 6:16 PM, Guenter Roeck wrote: > On 03/30/2016 01:37 AM, Alexandre Courbot wrote: >> >> On Wed, Mar 30, 2016 at 3:20 AM, Guenter Roeck wrote: >>> >>> Since commit ff2b13592299 ("gpio: make the gpiochip a real device"), >>> attempts to add a gpio chip prior to gpiolib

Re: [PATCH] net: mvneta: explicitly disable BM on 64bit platform

Hi Gregory, On Wed, 30 Mar 2016 17:11:41 +0200 Gregory CLEMENT wrote: > Hi Jisheng, > > On mer., mars 30 2016, Jisheng Zhang wrote: > > > The mvneta BM can't work on 64bit platform, as the BM hardware expects > > buf virtual address to be placed in the first four bytes of mapped > > buffer,

Re: zram: per-cpu compression streams

Hello Sergey, On Thu, Mar 31, 2016 at 10:26:26AM +0900, Sergey Senozhatsky wrote: > Hello, > > On (03/31/16 07:12), Minchan Kim wrote: > [..] > > > I used a bit different script. no `buffer_compress_percentage' option, > > > because it provide "a mix of random data and zeroes" > > > > Normally,

Re: zram: per-cpu compression streams

Hello Sergey, On Thu, Mar 31, 2016 at 10:26:26AM +0900, Sergey Senozhatsky wrote: > Hello, > > On (03/31/16 07:12), Minchan Kim wrote: > [..] > > > I used a bit different script. no `buffer_compress_percentage' option, > > > because it provide "a mix of random data and zeroes" > > > > Normally,

[PATCH net-next 3/6] macvtap: socket rx busy polling support

Signed-off-by: Jason Wang --- drivers/net/macvtap.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index 95394ed..1891aff 100644 --- a/drivers/net/macvtap.c +++ b/drivers/net/macvtap.c @@ -20,6 +20,7 @@ #include

[PATCH net-next 3/6] macvtap: socket rx busy polling support

Signed-off-by: Jason Wang --- drivers/net/macvtap.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index 95394ed..1891aff 100644 --- a/drivers/net/macvtap.c +++ b/drivers/net/macvtap.c @@ -20,6 +20,7 @@ #include #include #include

[PATCH net-next 6/6] vhost_net: net device rx busy polling support

This patch let vhost_net try rx busy polling of underlying net device when busy polling is enabled. Test shows some improvement on TCP_RR: smp=1 queue=1 size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/ 1/ 1/ +4%/ +3%/ +3%/ +3%/ +22% 1/50/ +2%/ +2%/ +2%/

[PATCH net-next 6/6] vhost_net: net device rx busy polling support

This patch let vhost_net try rx busy polling of underlying net device when busy polling is enabled. Test shows some improvement on TCP_RR: smp=1 queue=1 size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/ 1/ 1/ +4%/ +3%/ +3%/ +3%/ +22% 1/50/ +2%/ +2%/ +2%/

平时最多也就联系了三千家，全球还有十几万客户在哪里？

您好: 您还在用ali平台开发外贸客户? 还在使用展会宣传企业和产品? 你out了!!! 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？ 加QQ1286754208给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。

[PATCH net-next 5/6] net: export napi_by_id()

This patch exports napi_by_id() which will be used by vhost_net socket busy polling. Signed-off-by: Jason Wang --- include/net/busy_poll.h | 1 + net/core/dev.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/net/busy_poll.h

平时最多也就联系了三千家，全球还有十几万客户在哪里？

您好: 您还在用ali平台开发外贸客户? 还在使用展会宣传企业和产品? 你out了!!! 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？ 加QQ1286754208给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。

[PATCH net-next 5/6] net: export napi_by_id()

This patch exports napi_by_id() which will be used by vhost_net socket busy polling. Signed-off-by: Jason Wang --- include/net/busy_poll.h | 1 + net/core/dev.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h

[PATCH net-next 0/6] net device rx busy polling support in vhost_net

Hi all: This series try to add net device rx busy polling support in vhost_net. This is done through: - adding socket rx busy polling support for tun/macvtap by marking napi_id. - vhost_net will try to find the net device through napi_id and do busy polling if possible. TCP_RR tests on two

[PATCH net-next 4/6] net: core: factor out core busy polling logic to sk_busy_loop_once()

This patch factors out core logic of busy polling to sk_busy_loop_once() in order to be reused by other modules. Signed-off-by: Jason Wang --- include/net/busy_poll.h | 7 ++ net/core/dev.c | 59 - 2 files

[PATCH net-next 1/6] net: skbuff: don't use union for napi_id and sender_cpu

We use a union for napi_id and send_cpu, this is ok for most of the cases except when we want to support busy polling for tun which needs napi_id to be stored and passed to socket during tun_net_xmit(). In this case, napi_id was overridden with sender_cpu before tun_net_xmit() was called if XPS

[PATCH net-next 2/6] tuntap: socket rx busy polling support

Signed-off-by: Jason Wang --- drivers/net/tun.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index afdf950..950faf5 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -69,6 +69,7 @@ #include #include

[PATCH net-next 1/6] net: skbuff: don't use union for napi_id and sender_cpu

We use a union for napi_id and send_cpu, this is ok for most of the cases except when we want to support busy polling for tun which needs napi_id to be stored and passed to socket during tun_net_xmit(). In this case, napi_id was overridden with sender_cpu before tun_net_xmit() was called if XPS

[PATCH net-next 2/6] tuntap: socket rx busy polling support

Signed-off-by: Jason Wang --- drivers/net/tun.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index afdf950..950faf5 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -69,6 +69,7 @@ #include #include #include +#include

[PATCH net-next 0/6] net device rx busy polling support in vhost_net

Hi all: This series try to add net device rx busy polling support in vhost_net. This is done through: - adding socket rx busy polling support for tun/macvtap by marking napi_id. - vhost_net will try to find the net device through napi_id and do busy polling if possible. TCP_RR tests on two

[PATCH net-next 4/6] net: core: factor out core busy polling logic to sk_busy_loop_once()

This patch factors out core logic of busy polling to sk_busy_loop_once() in order to be reused by other modules. Signed-off-by: Jason Wang --- include/net/busy_poll.h | 7 ++ net/core/dev.c | 59 - 2 files changed, 41 insertions(+),

Re: [PATCH] tpm: remove redundant code from self-test functions

On Wed, Mar 30, 2016 at 04:20:45PM +0300, Jarkko Sakkinen wrote: > - rc = be32_to_cpu(cmd.header.out.return_code); > if (rc == TPM_ERR_DISABLED || rc == TPM_ERR_DEACTIVATED) { This line is the entire reason it is open coded, I see it being removed, but I don't see how

Re: [PATCH] tpm: remove redundant code from self-test functions

On Wed, Mar 30, 2016 at 04:20:45PM +0300, Jarkko Sakkinen wrote: > - rc = be32_to_cpu(cmd.header.out.return_code); > if (rc == TPM_ERR_DISABLED || rc == TPM_ERR_DEACTIVATED) { This line is the entire reason it is open coded, I see it being removed, but I don't see how

[PATCH] .mailmap: Add Christophe Ricard

Different computers had different settings in the mail client. Some contributions appear as Christophe Ricard, others as Christophe RICARD. Signed-off-by: Christophe Ricard --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index

[PATCH] .mailmap: Add Christophe Ricard

Different computers had different settings in the mail client. Some contributions appear as Christophe Ricard, others as Christophe RICARD. Signed-off-by: Christophe Ricard --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 7e6c533..90c0aef 100644 ---

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On 30 March 2016 at 19:24, Felipe Balbi wrote: >>> >> >> > >>> >> >> > Seems you don't want to guarantee charger type detection is done >>> >> >> > before gadget connection(pullup DP), right? >>> >> >> > I see you call usb_charger_detect_type() in each gadget usb >>> >> >> >

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On 30 March 2016 at 19:24, Felipe Balbi wrote: >>> >> >> > >>> >> >> > Seems you don't want to guarantee charger type detection is done >>> >> >> > before gadget connection(pullup DP), right? >>> >> >> > I see you call usb_charger_detect_type() in each gadget usb >>> >> >> > state >>> >> >>

Re: [PATCH v2] tty/serial/8250: fix RS485 half-duplex RX

On Thu, Mar 24, 2016 at 9:03 AM, wrote: > From: Yegor Yefremov > > When in half-duplex mode RX will be disabled before TX, but not > enabled after deactivating transmitter. This patch enables > UART_IER_RLSI and UART_IER_RDI interrupts

Re: [PATCH v2] tty/serial/8250: fix RS485 half-duplex RX

On Thu, Mar 24, 2016 at 9:03 AM, wrote: > From: Yegor Yefremov > > When in half-duplex mode RX will be disabled before TX, but not > enabled after deactivating transmitter. This patch enables > UART_IER_RLSI and UART_IER_RDI interrupts after TX is over. > > Cc: Matwey V. Kornilov >

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On 30 March 2016 at 18:58, Jun Li wrote: >> >> >> > Seems you don't want to guarantee charger type detection is done >> >> >> > before gadget connection(pullup DP), right? >> >> >> > I see you call usb_charger_detect_type() in each gadget usb >> >> >> > state >> >> >> changes. >>

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On 30 March 2016 at 18:58, Jun Li wrote: >> >> >> > Seems you don't want to guarantee charger type detection is done >> >> >> > before gadget connection(pullup DP), right? >> >> >> > I see you call usb_charger_detect_type() in each gadget usb >> >> >> > state >> >> >> changes. >> >> >> >> >> >> I

Re: [PATCH V2 3/3] sched/deadline: Tracepoints for deadline scheduler

Hi, On 29/03/16 15:25, Steven Rostedt wrote: > On Tue, 29 Mar 2016 16:12:38 -0300 > Daniel Bristot de Oliveira wrote: > > > On 03/29/2016 02:13 PM, Steven Rostedt wrote: > > >> -0 [007] d..3 78377.688969: sched_switch: > > >> prev_comm=swapper/7 prev_pid=0

Re: [PATCH V2 3/3] sched/deadline: Tracepoints for deadline scheduler

Hi, On 29/03/16 15:25, Steven Rostedt wrote: > On Tue, 29 Mar 2016 16:12:38 -0300 > Daniel Bristot de Oliveira wrote: > > > On 03/29/2016 02:13 PM, Steven Rostedt wrote: > > >> -0 [007] d..3 78377.688969: sched_switch: > > >> prev_comm=swapper/7 prev_pid=0 prev_prio=120

Re: [PATCH v16 22/23] tracing: Add hist trigger 'log2' modifier

Hi Namhyung, On 03/29/2016 05:17 PM, Namhyung Kim wrote: > On Tue, Mar 29, 2016 at 12:01:40PM +0200, Daniel Wagner wrote: >> cat /sys/kernel/debug/tracing/events/test/latency_complete/hist >> # event histogram >> # >> # trigger info: >>

Re: [PATCH v16 22/23] tracing: Add hist trigger 'log2' modifier

Hi Namhyung, On 03/29/2016 05:17 PM, Namhyung Kim wrote: > On Tue, Mar 29, 2016 at 12:01:40PM +0200, Daniel Wagner wrote: >> cat /sys/kernel/debug/tracing/events/test/latency_complete/hist >> # event histogram >> # >> # trigger info: >>

Re: [PATCH 0/3] idle, Honor Hardware Disabled States

> Len, > > Your patch does > > + skl_cstates[5].disabled = 1;/* C8-SKL */ > + skl_cstates[6].disabled = 1;/* C9-SKL */ > > and I don't think that is correct for SKY-H. For https://bugzilla.kernel.org/show_bug.cgi?id=109081 it is correct. > Your patch does not take into

Re: [PATCH 0/3] idle, Honor Hardware Disabled States

> Len, > > Your patch does > > + skl_cstates[5].disabled = 1;/* C8-SKL */ > + skl_cstates[6].disabled = 1;/* C9-SKL */ > > and I don't think that is correct for SKY-H. For https://bugzilla.kernel.org/show_bug.cgi?id=109081 it is correct. > Your patch does not take into

Re: [PATCH v4 6/9] ARM: dts: Add initial gpio setting of MMC2 device for exynos3250-monk

On 31.03.2016 11:48, Chanwoo Choi wrote: > This patch adds initial pin configuration of MMC2 device on exynos3250-monk > board because the MMC2 gpio pin (gpk2[0-6]) are NC (not connected) state. > > Suggested-by: Krzysztof Kozlowski > Signed-off-by: Chanwoo Choi

Re: [PATCH v4 6/9] ARM: dts: Add initial gpio setting of MMC2 device for exynos3250-monk

On 31.03.2016 11:48, Chanwoo Choi wrote: > This patch adds initial pin configuration of MMC2 device on exynos3250-monk > board because the MMC2 gpio pin (gpk2[0-6]) are NC (not connected) state. > > Suggested-by: Krzysztof Kozlowski > Signed-off-by: Chanwoo Choi > Reviewed-by: Krzysztof

Re: [PATCH v4 1/9] ARM: dts: Add initial pin configuration for exynos3250-rinato

On 31.03.2016 11:47, Chanwoo Choi wrote: > This patch adds initial pin configuration using pinctrl subsystem > to reduce leakage power-consumption of gpio pins in normal state. > All pins included in this patch are NC (not connected) pin. > > Cc: Kukjin Kim > Cc: Krzysztof

Re: [PATCH v4 1/9] ARM: dts: Add initial pin configuration for exynos3250-rinato

On 31.03.2016 11:47, Chanwoo Choi wrote: > This patch adds initial pin configuration using pinctrl subsystem > to reduce leakage power-consumption of gpio pins in normal state. > All pins included in this patch are NC (not connected) pin. > > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski >

[git pull] vfs fix

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus for you to fetch changes up to

Re: [PATCH] ACPICA: Remove unnecessary "\n" from an ACPI_INFO boot message

On Wed, 2016-03-30 at 22:11 -0300, Daniel Bristot de Oliveira wrote: > On 03/29/2016 04:09 PM, Moore, Robert wrote: > > Actually, I did in fact put that there to break up the output after the > > tables are loaded. Is this a problem? > Well, I do not believe that there is a real problem on it. >

[git pull] vfs fix

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus for you to fetch changes up to

Re: [PATCH] ACPICA: Remove unnecessary "\n" from an ACPI_INFO boot message

On Wed, 2016-03-30 at 22:11 -0300, Daniel Bristot de Oliveira wrote: > On 03/29/2016 04:09 PM, Moore, Robert wrote: > > Actually, I did in fact put that there to break up the output after the > > tables are loaded. Is this a problem? > Well, I do not believe that there is a real problem on it. >

[PATCH 3/9] x86 tsc_msr: Update comments, expand definitions

From: Len Brown Syntax only, no functional change. Signed-off-by: Len Brown --- arch/x86/kernel/tsc_msr.c | 36 ++-- 1 file changed, 10 insertions(+), 26 deletions(-) diff --git a/arch/x86/kernel/tsc_msr.c

[PATCH 3/9] x86 tsc_msr: Update comments, expand definitions

From: Len Brown Syntax only, no functional change. Signed-off-by: Len Brown --- arch/x86/kernel/tsc_msr.c | 36 ++-- 1 file changed, 10 insertions(+), 26 deletions(-) diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c index d460ef1..3a866bc

Re: [PART1 RFC v3 10/12] svm: Do not expose x2APIC when enable AVIC

Hi Radim, On 03/19/2016 03:59 AM, Radim Krčmář wrote: 2016-03-18 01:09-0500, Suravee Suthikulpanit: From: Suravee Suthikulpanit Since AVIC only virtualizes xAPIC hardware for the guest, we need to: * Intercept APIC BAR msr accesses to disable x2APIC *

Re: [PART1 RFC v3 10/12] svm: Do not expose x2APIC when enable AVIC

Hi Radim, On 03/19/2016 03:59 AM, Radim Krčmář wrote: 2016-03-18 01:09-0500, Suravee Suthikulpanit: From: Suravee Suthikulpanit Since AVIC only virtualizes xAPIC hardware for the guest, we need to: * Intercept APIC BAR msr accesses to disable x2APIC * Intercept CPUID access to not

[PATCH 1/9] x86 tsc_msr: Identify Intel-specific code

From: Len Brown try_msr_calibrate_tsc() is currently Intel-specific, and should not execute on any other vendor's parts. Signed-off-by: Len Brown --- arch/x86/kernel/tsc_msr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH 5/9] x86 tsc_msr: Add Airmont reference clock values

From: Len Brown per the Intel 64 and IA-32 Architecture Software Developer's Manual... Add the reference clock for Intel Atom Processors Based on the Airmont Microarchitecture. Reported-by: Stephane Gasparini Signed-off-by: Len Brown

[PATCH 2/9] x86 tsc_msr: Remove debugging messages

From: Len Brown Debugging messages are not necessary after all of the possible hardware failures that never occur. Instead, this code can simply return 0. This code also doesn't need to print in the success case. tsc_init() already prints the TSC frequency, and apic=debug

[PATCH 1/9] x86 tsc_msr: Identify Intel-specific code

From: Len Brown try_msr_calibrate_tsc() is currently Intel-specific, and should not execute on any other vendor's parts. Signed-off-by: Len Brown --- arch/x86/kernel/tsc_msr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c index

[PATCH 5/9] x86 tsc_msr: Add Airmont reference clock values

From: Len Brown per the Intel 64 and IA-32 Architecture Software Developer's Manual... Add the reference clock for Intel Atom Processors Based on the Airmont Microarchitecture. Reported-by: Stephane Gasparini Signed-off-by: Len Brown --- arch/x86/kernel/tsc_msr.c | 5 - 1 file changed,

[PATCH 2/9] x86 tsc_msr: Remove debugging messages

From: Len Brown Debugging messages are not necessary after all of the possible hardware failures that never occur. Instead, this code can simply return 0. This code also doesn't need to print in the success case. tsc_init() already prints the TSC frequency, and apic=debug is available if

[PATCH 7/9] x86 tsc_msr: Remove irqoff around MSR-based TSC enumeration

From: Len Brown Remove the irqoff/irqon around MSR-based TSC enumeration, as it is not necessary. Also rename: try_msr_calibrate_tsc() to cpu_khz_from_msr(), as that better describes what the routine does. Signed-off-by: Len Brown ---

[PATCH 6/9] x86 tsc_msr: Extend to include Intel Core Architecture

From: Len Brown tsc_msr is used to quickly and reliably enumerate the CPU/TSC frequencies at boot time For the Intel Atom Architecture. Extend tsc_msr to include recent Intel Core Architecture. As this code discovers BCLK, it also sets lapic_timer_frequency, which allows

[PATCH 7/9] x86 tsc_msr: Remove irqoff around MSR-based TSC enumeration

From: Len Brown Remove the irqoff/irqon around MSR-based TSC enumeration, as it is not necessary. Also rename: try_msr_calibrate_tsc() to cpu_khz_from_msr(), as that better describes what the routine does. Signed-off-by: Len Brown --- arch/x86/include/asm/tsc.h | 3 +-- arch/x86/kernel/tsc.c

[PATCH 6/9] x86 tsc_msr: Extend to include Intel Core Architecture

From: Len Brown tsc_msr is used to quickly and reliably enumerate the CPU/TSC frequencies at boot time For the Intel Atom Architecture. Extend tsc_msr to include recent Intel Core Architecture. As this code discovers BCLK, it also sets lapic_timer_frequency, which allows LAPIC timer

[PATCH 4/9] x86 tsc_msr: Correct Silvermont reference clock values

From: Len Brown Atom processors use a 19.2 MHz crystal oscillator. Early processors generate 100 MHz via 19.2 MHz * 26 / 5 = 99.84 MHz. Later preocessor generate 100 MHz via 19.2 MHz * 125 / 24 = 100 MHz. Update the Silvermont-based tables accordingly, matching the

[PATCH 4/9] x86 tsc_msr: Correct Silvermont reference clock values

From: Len Brown Atom processors use a 19.2 MHz crystal oscillator. Early processors generate 100 MHz via 19.2 MHz * 26 / 5 = 99.84 MHz. Later preocessor generate 100 MHz via 19.2 MHz * 125 / 24 = 100 MHz. Update the Silvermont-based tables accordingly, matching the Software Developers Manual.

[PATCH 9/9] x86 tsc: enumerate BXT tsc_khz via CPUID

From: Bin Gao Hard code the BXT crystal clock (aka ART - Always Running Timer) to 19.200 MHz, and use CPUID leaf 0x15 to determine the BXT TSC frequency. Use tsc_khz to sanity check BXT cpu_khz, which can be erroneous in some configurations. Signed-off-by: Bin Gao

[PATCH 8/9] x86 tsc: enumerate SKL cpu_khz and tsc_khz via CPUID

From: Len Brown Skylake CPU base-frequency and TSC frequency may differ by up to 2%. Enumerate CPU and TSC frequencies separately, allowing cpu_khz and tsc_khz to differ. The existing CPU frequency calibration mechanism is unchanged. However, CPUID extensions are

[PATCH 0/9] x86: TSC calibration update

cpu_khz and tsc_khz initialization can be unreliable and expensive. They are initialized in tsc_init()/native_calibrate_tsc(), which prints: pr_info("Detected %lu.%03lu MHz processor\n", cpu_khz...) native_calibrate_cpu() first tries quick_pit_calibrate(), which can take over 50.0M cycles to

[PATCH 9/9] x86 tsc: enumerate BXT tsc_khz via CPUID

From: Bin Gao Hard code the BXT crystal clock (aka ART - Always Running Timer) to 19.200 MHz, and use CPUID leaf 0x15 to determine the BXT TSC frequency. Use tsc_khz to sanity check BXT cpu_khz, which can be erroneous in some configurations. Signed-off-by: Bin Gao [lenb: simplified]

[PATCH 8/9] x86 tsc: enumerate SKL cpu_khz and tsc_khz via CPUID

From: Len Brown Skylake CPU base-frequency and TSC frequency may differ by up to 2%. Enumerate CPU and TSC frequencies separately, allowing cpu_khz and tsc_khz to differ. The existing CPU frequency calibration mechanism is unchanged. However, CPUID extensions are preferred, when available.

[PATCH 0/9] x86: TSC calibration update

cpu_khz and tsc_khz initialization can be unreliable and expensive. They are initialized in tsc_init()/native_calibrate_tsc(), which prints: pr_info("Detected %lu.%03lu MHz processor\n", cpu_khz...) native_calibrate_cpu() first tries quick_pit_calibrate(), which can take over 50.0M cycles to

RE: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

> -Original Message- > From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com] > Sent: Tuesday, March 29, 2016 10:51 PM > To: Rajesh Bhagat > Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; Sriram Dash

RE: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

> -Original Message- > From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com] > Sent: Tuesday, March 29, 2016 10:51 PM > To: Rajesh Bhagat > Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; Sriram Dash > Subject: Re: [PATCH] usb: xhci: Fix

Re: [RFCv7 PATCH 00/10] sched: scheduler-driven CPU frequency selection

Hi Steve, On Wed, Mar 30, 2016 at 06:35:23PM -0700, Steve Muckle wrote: > This series was dropped in favor of Rafael's schedutil. But on the > chance that you're still curious about the test setup used to quantify > the series I'll explain below. I will catch up and learn both. > These results

Re: [RFCv7 PATCH 00/10] sched: scheduler-driven CPU frequency selection

Hi Steve, On Wed, Mar 30, 2016 at 06:35:23PM -0700, Steve Muckle wrote: > This series was dropped in favor of Rafael's schedutil. But on the > chance that you're still curious about the test setup used to quantify > the series I'll explain below. I will catch up and learn both. > These results

[PATCH RESEND v2 1/6] sched/fair: Generalize the load/util averages resolution definition

Integer metric needs fixed point arithmetic. In sched/fair, a few metrics, e.g., weight, load, load_avg, util_avg, freq, and capacity, may have different fixed point ranges, which makes their update and usage error-prone. In order to avoid the errors relating to the fixed point range, we definie

[PATCH RESEND v2 4/6] sched/fair: Remove scale_load_down() for load_avg

Currently, load_avg = scale_load_down(load) * runnable%. The extra scaling down of load does not make much sense, because load_avg is primarily THE load and on top of that, we take runnable time into account. We therefore remove scale_load_down() for load_avg. But we need to carefully consider

[PATCH RESEND v2 1/6] sched/fair: Generalize the load/util averages resolution definition

Integer metric needs fixed point arithmetic. In sched/fair, a few metrics, e.g., weight, load, load_avg, util_avg, freq, and capacity, may have different fixed point ranges, which makes their update and usage error-prone. In order to avoid the errors relating to the fixed point range, we definie

[PATCH RESEND v2 4/6] sched/fair: Remove scale_load_down() for load_avg

Currently, load_avg = scale_load_down(load) * runnable%. The extra scaling down of load does not make much sense, because load_avg is primarily THE load and on top of that, we take runnable time into account. We therefore remove scale_load_down() for load_avg. But we need to carefully consider

[PATCH RESEND v2 6/6] sched/fair: Remove unconditionally inactive code

The increased load resolution (fixed point arithmetic range) is unconditionally deactivated with #if 0, so it is effectively broken. But the increased load range is still used somewhere (e.g., in Google), so we keep this feature. The reconciliation is we define CONFIG_CFS_INCREASE_LOAD_RANGE and

[PATCH RESEND v2 5/6] sched/fair: Rename scale_load() and scale_load_down()

Rename scale_load() and scale_load_down() to user_to_kernel_load() and kernel_to_user_load() respectively, to allow the names to bear what they are really about. Signed-off-by: Yuyang Du [update calculate_imbalance] Signed-off-by: Vincent Guittot

[PATCH RESEND v2 6/6] sched/fair: Remove unconditionally inactive code

The increased load resolution (fixed point arithmetic range) is unconditionally deactivated with #if 0, so it is effectively broken. But the increased load range is still used somewhere (e.g., in Google), so we keep this feature. The reconciliation is we define CONFIG_CFS_INCREASE_LOAD_RANGE and

[PATCH RESEND v2 5/6] sched/fair: Rename scale_load() and scale_load_down()

Rename scale_load() and scale_load_down() to user_to_kernel_load() and kernel_to_user_load() respectively, to allow the names to bear what they are really about. Signed-off-by: Yuyang Du [update calculate_imbalance] Signed-off-by: Vincent Guittot Signed-off-by: Yuyang Du ---

[PATCH RESEND v2 3/6] sched/fair: Add introduction to the sched load avg metrics

These sched metrics have become complex enough. We introduce them at their definition. Signed-off-by: Yuyang Du --- include/linux/sched.h | 60 +-- 1 file changed, 49 insertions(+), 11 deletions(-) diff --git

[PATCH RESEND v2 3/6] sched/fair: Add introduction to the sched load avg metrics

These sched metrics have become complex enough. We introduce them at their definition. Signed-off-by: Yuyang Du --- include/linux/sched.h | 60 +-- 1 file changed, 49 insertions(+), 11 deletions(-) diff --git a/include/linux/sched.h

[PATCH RESEND v2 0/6] sched/fair: Clean up sched metric definitions

Hi Peter, This patch searies is left in last year, and thus I resend it. Would you please give it a look? The previous version is at http://thread.gmane.org/gmane.linux.kernel/2068513 This series cleans up the sched metrics, changes include: (1) Define SCHED_FIXEDPOINT_SHIFT for all fixed point

[PATCH RESEND v2 2/6] sched/fair: Remove SCHED_LOAD_SHIFT and SCHED_LOAD_SCALE

After cleaning up the sched metrics, these two definitions that cause ambiguity are not needed any more. Use NICE_0_LOAD_SHIFT and NICE_0_LOAD instead (the names suggest clearly who they are). Suggested-by: Ben Segall Signed-off-by: Yuyang Du ---

[PATCH RESEND v2 0/6] sched/fair: Clean up sched metric definitions

Hi Peter, This patch searies is left in last year, and thus I resend it. Would you please give it a look? The previous version is at http://thread.gmane.org/gmane.linux.kernel/2068513 This series cleans up the sched metrics, changes include: (1) Define SCHED_FIXEDPOINT_SHIFT for all fixed point

[PATCH RESEND v2 2/6] sched/fair: Remove SCHED_LOAD_SHIFT and SCHED_LOAD_SCALE

After cleaning up the sched metrics, these two definitions that cause ambiguity are not needed any more. Use NICE_0_LOAD_SHIFT and NICE_0_LOAD instead (the names suggest clearly who they are). Suggested-by: Ben Segall Signed-off-by: Yuyang Du --- kernel/sched/fair.c | 4 ++--

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

Hi Bao, On 2016/03/31 at 10:52, Baoquan He wrote: > On 03/31/16 at 10:43am, Minfei Huang wrote: >> On 03/30/16 at 08:30pm, Baoquan He wrote: >>> Hi Xunlei, >>> >>> I have two questions. >>> >>> One is do we still need Minfei's patch if this patch is applied since >>> you have completely delete

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

Hi Bao, On 2016/03/31 at 10:52, Baoquan He wrote: > On 03/31/16 at 10:43am, Minfei Huang wrote: >> On 03/30/16 at 08:30pm, Baoquan He wrote: >>> Hi Xunlei, >>> >>> I have two questions. >>> >>> One is do we still need Minfei's patch if this patch is applied since >>> you have completely delete

Re: [PATCH v2] gpio: pca953x: Use correct u16 value for register word write

On 30/03/2016 2:49 PM, Yong Li wrote: The current implementation only uses the first byte in val, the second byte is always 0. Change it to use cpu_to_le16 to write the two bytes into the register Signed-off-by: Yong Li Reviewed-by: Phil Reid

Re: [PATCH v2] gpio: pca953x: Use correct u16 value for register word write

On 30/03/2016 2:49 PM, Yong Li wrote: The current implementation only uses the first byte in val, the second byte is always 0. Change it to use cpu_to_le16 to write the two bytes into the register Signed-off-by: Yong Li Reviewed-by: Phil Reid --- drivers/gpio/gpio-pca953x.c | 3 ++- 1

Re:����Proces denture tools

Dear Sir Hello! Our company is the Guangzhou Honda and China FAW suppliers. We have been providing quality products and services for them. Our company's main products: Graphite machining end mill The denture machining tool Zirconia processing tool PCD tools CNC inserts Milling toolholder

Re:����Proces denture tools

Dear Sir Hello! Our company is the Guangzhou Honda and China FAW suppliers. We have been providing quality products and services for them. Our company's main products: Graphite machining end mill The denture machining tool Zirconia processing tool PCD tools CNC inserts Milling toolholder

Re:����Proces denture tools

Dear Sir Hello! Our company is the Guangzhou Honda and China FAW suppliers. We have been providing quality products and services for them. Our company's main products: Graphite machining end mill The denture machining tool Zirconia processing tool PCD tools CNC inserts Milling toolholder

Re:����Proces denture tools

Dear Sir Hello! Our company is the Guangzhou Honda and China FAW suppliers. We have been providing quality products and services for them. Our company's main products: Graphite machining end mill The denture machining tool Zirconia processing tool PCD tools CNC inserts Milling toolholder

[PATCH v4] mmc: Provide tracepoints for request processing

This patch provides some tracepoints for the lifecycle of a mmc request from starting to completion to help with performance analysis of MMC subsystem. Changes since v3: - Add "retries" and "re-tune state" in the trace print. - Move trace_mmc_request_start() to __mmc_start_request() function to

[PATCH v4] mmc: Provide tracepoints for request processing

This patch provides some tracepoints for the lifecycle of a mmc request from starting to completion to help with performance analysis of MMC subsystem. Changes since v3: - Add "retries" and "re-tune state" in the trace print. - Move trace_mmc_request_start() to __mmc_start_request() function to

[PATCH v2] spi: rockchip: fix warning of static check

Use dma_request_chan instead of dma_request_slave_channel, in this case we can check EPROBE_DEFER without static warning. Reported-by: Dan Carpenter Cc: Doug Anderson Cc: Dan Carpenter Signed-off-by: Shawn Lin

[PATCH v2] spi: rockchip: fix warning of static check

Use dma_request_chan instead of dma_request_slave_channel, in this case we can check EPROBE_DEFER without static warning. Reported-by: Dan Carpenter Cc: Doug Anderson Cc: Dan Carpenter Signed-off-by: Shawn Lin --- Changes in v2: - use dma_request_chan and replace IS_ERR_OR_NULL() with

Re: [PATCH v7 1/5] staging/android: add num_fences field to struct sync_file_info

On Wed, Mar 30, 2016 at 11:53:38PM -0300, Gustavo Padovan wrote: > Hi Greg, > > 2016-03-30 Greg Kroah-Hartman : > > > On Thu, Mar 03, 2016 at 04:40:42PM -0300, Gustavo Padovan wrote: > > > From: Gustavo Padovan > > > > > > > >

Re: [PATCH v7 1/5] staging/android: add num_fences field to struct sync_file_info

On Wed, Mar 30, 2016 at 11:53:38PM -0300, Gustavo Padovan wrote: > Hi Greg, > > 2016-03-30 Greg Kroah-Hartman : > > > On Thu, Mar 03, 2016 at 04:40:42PM -0300, Gustavo Padovan wrote: > > > From: Gustavo Padovan > > > > > > > > Gustavo, can you resend both series of your android patches so I

  1   2   3   4   5   6   7   8   9   10   >