[PATCH 1/7] lightnvm: enable to send hint to erase command

Erases might be subject to host hints. An example is multi-plane programming to erase blocks in parallel. Enable targets to specify this hints. Signed-off-by: Javier González --- drivers/lightnvm/core.c | 9 ++--- drivers/lightnvm/gennvm.c| 5 ++---

Re: [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms

Hello Richard, On Thu, Oct 27, 2016 at 06:04:06PM +0200, Richard Genoud wrote: > diff --git a/drivers/tty/serial/atmel_serial.c > b/drivers/tty/serial/atmel_serial.c > index fd8aa1f4ba78..168b10cad47b 100644 > --- a/drivers/tty/serial/atmel_serial.c > +++ b/drivers/tty/serial/atmel_serial.c > @@

[PATCH 5/7] lightnvm: export set bad block table

Bad blocks should be managed by block owners. This would be either targets for data blocks or sysblk for system blocks. In order to support this, export two functions: One to mark a block as an specific type (e.g., bad block) and another to update the bad block table on the device. Move bad

[PATCH 4/7] lightnvm: drop reserve and release LUN callbacks

From: Javier González On target initialization, targets use callbacks to the media manager to configure the LUNs they use. In order to simplify the flow, drop this callbacks and manage everything internally on the media manager. By making use of the newly introduce LUN

[PATCH 1/7] lightnvm: enable to send hint to erase command

Erases might be subject to host hints. An example is multi-plane programming to erase blocks in parallel. Enable targets to specify this hints. Signed-off-by: Javier González --- drivers/lightnvm/core.c | 9 ++--- drivers/lightnvm/gennvm.c| 5 ++--- drivers/lightnvm/rrpc.c | 2

Re: [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms

Hello Richard, On Thu, Oct 27, 2016 at 06:04:06PM +0200, Richard Genoud wrote: > diff --git a/drivers/tty/serial/atmel_serial.c > b/drivers/tty/serial/atmel_serial.c > index fd8aa1f4ba78..168b10cad47b 100644 > --- a/drivers/tty/serial/atmel_serial.c > +++ b/drivers/tty/serial/atmel_serial.c > @@

[PATCH 5/7] lightnvm: export set bad block table

Bad blocks should be managed by block owners. This would be either targets for data blocks or sysblk for system blocks. In order to support this, export two functions: One to mark a block as an specific type (e.g., bad block) and another to update the bad block table on the device. Move bad

[PATCH 4/7] lightnvm: drop reserve and release LUN callbacks

From: Javier González On target initialization, targets use callbacks to the media manager to configure the LUNs they use. In order to simplify the flow, drop this callbacks and manage everything internally on the media manager. By making use of the newly introduce LUN management structure, the

[PATCH 0/7] LightNVM patchset V2

V2: Rebase patches on Matias' for-next Javier González (7): lightnvm: enable to send hint to erase command lightnvm: do not decide on device blocks lightnvm: manage block list on LUN owner lightnvm: drop reserve and release LUN callbacks lightnvm: export set bad block table lightnvm:

[PATCH 0/7] LightNVM patchset V2

V2: Rebase patches on Matias' for-next Javier González (7): lightnvm: enable to send hint to erase command lightnvm: do not decide on device blocks lightnvm: manage block list on LUN owner lightnvm: drop reserve and release LUN callbacks lightnvm: export set bad block table lightnvm:

[PATCH 7/7] lightnvm: rrpc: split bios of size > 256kb

rrpc cannot handle bios of size > 256kb due to NVMe using a 64 bit bitmap to signal I/O completion. If a larger bio comes, split it explicitly. Signed-off-by: Javier González --- drivers/lightnvm/rrpc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH 7/7] lightnvm: rrpc: split bios of size > 256kb

rrpc cannot handle bios of size > 256kb due to NVMe using a 64 bit bitmap to signal I/O completion. If a larger bio comes, split it explicitly. Signed-off-by: Javier González --- drivers/lightnvm/rrpc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/lightnvm/rrpc.c

[PATCH 3/7] lightnvm: manage block list on LUN owner

From: Javier González LUNs can be exclusively owned by a target through the media manager's reserve_lun function. In this case, the target should implement its own provisioning and manage internally the free/used/bad block list. This patch introduces a LUN management

[PATCH 6/7] lightnvm: add ECC error codes

Add ECC error codes to enable the appropriate handling in the target. Signed-off-by: Javier González --- include/linux/lightnvm.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/lightnvm.h b/include/linux/lightnvm.h index e3ccaff..33643ae 100644 ---

[PATCH 3/7] lightnvm: manage block list on LUN owner

From: Javier González LUNs can be exclusively owned by a target through the media manager's reserve_lun function. In this case, the target should implement its own provisioning and manage internally the free/used/bad block list. This patch introduces a LUN management structure that can be

[PATCH 6/7] lightnvm: add ECC error codes

Add ECC error codes to enable the appropriate handling in the target. Signed-off-by: Javier González --- include/linux/lightnvm.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/lightnvm.h b/include/linux/lightnvm.h index e3ccaff..33643ae 100644 ---

[patch v2 2/2] drivers/platform/x86: add mlxcpld-hotplug driver registration to mlx-platform driver

Add calls for mlxcpld-hotplug platform driver registration/unregistration and add platform hotplug data configurations. This driver, when registered within system will handle system hot-plug events for the power suppliers, power cables and fans (insertion and removing). These events are controlled

[patch v2 2/2] drivers/platform/x86: add mlxcpld-hotplug driver registration to mlx-platform driver

Add calls for mlxcpld-hotplug platform driver registration/unregistration and add platform hotplug data configurations. This driver, when registered within system will handle system hot-plug events for the power suppliers, power cables and fans (insertion and removing). These events are controlled

[patch v2 1/2] drivers/platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86

Move module mlx-platform.c from arch/x86/platform/mellanox/ to drivers/platform/x86/. Remove folder arch/x86/platform/mellanox/ and update relevant Makefile and Kconfig. Signed-off-by: Vadim Pasternak v1->v2: Comments pointed out by Andy: - Use -M -C -n option in git

Re: [PATCH 4/4] Input: goodix - Support interchanging x and y coordinates in hardware

On 10/26/2016 06:18 PM, Rob Herring wrote: > On Thu, Oct 20, 2016 at 02:59:17PM -0500, Franklin S Cooper Jr wrote: >> On systems with a fixed display/touchscreen orientation it is important to >> pass in the "correct" x and y coordinates based on the orientation. >> Currently, to support

Re: [PATCH 4/4] Input: goodix - Support interchanging x and y coordinates in hardware

On 10/26/2016 06:18 PM, Rob Herring wrote: > On Thu, Oct 20, 2016 at 02:59:17PM -0500, Franklin S Cooper Jr wrote: >> On systems with a fixed display/touchscreen orientation it is important to >> pass in the "correct" x and y coordinates based on the orientation. >> Currently, to support

[patch v2 1/2] drivers/platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86

Move module mlx-platform.c from arch/x86/platform/mellanox/ to drivers/platform/x86/. Remove folder arch/x86/platform/mellanox/ and update relevant Makefile and Kconfig. Signed-off-by: Vadim Pasternak v1->v2: Comments pointed out by Andy: - Use -M -C -n option in git format-patch; ---

Re: [PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type

On 10/27/2016 10:26 AM, Eric Dumazet wrote: > On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote: >> We recently encountered a bug where a few customers using ibmveth on the >> same LPAR hit an issue where a TCP session hung when large receive was >> enabled. Closer analysis revealed that the

Re: [PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type

On 10/27/2016 10:26 AM, Eric Dumazet wrote: > On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote: >> We recently encountered a bug where a few customers using ibmveth on the >> same LPAR hit an issue where a TCP session hung when large receive was >> enabled. Closer analysis revealed that the

Re: [PATCH] thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode

On Thu, 27 Oct 2016, Lyude Paul wrote: > as well, can someone confirm this patch made it to the ibm-acpi-devel > list? When I originally sent this I realized I wasn't subscribed to the > list, so I'm guessing I might need to resend. I received it. I just didn't have the time to go over it in

Re: [PATCH] thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode

On Thu, 27 Oct 2016, Lyude Paul wrote: > as well, can someone confirm this patch made it to the ibm-acpi-devel > list? When I originally sent this I realized I wasn't subscribed to the > list, so I'm guessing I might need to resend. I received it. I just didn't have the time to go over it in

Fwd: Fujitsu PrimePower 450 with SPARC64 V & Linux support

I am trying to build Linux system on Fujitsu PrimePower 450 running by SPARC64 V CPUs. Does anyone have supportive materials (manuals, overviews, specs) about Fujitsu PP450 and SPARC64 V CPUs. Every kind of source material may be useful! All I have found from Internet, there is no Linux support

[PATCH 1/2] x86/prctl/uapi: remove ifdef for CHECKPOINT_RESTORE

As userspace knows nothing about kernel config, this ifdefs will make prctl constants invisible to userspace. Let it be clean'n'simple: remove ifdefs. If kernel has CONFIG_CHECKPOINT_RESTORE disabled, sys_prctl() will return -EINVAL for those prctls. Fixes: 2eefd8789698 ("x86/arch_prctl/vdso: Add

Fwd: Fujitsu PrimePower 450 with SPARC64 V & Linux support

I am trying to build Linux system on Fujitsu PrimePower 450 running by SPARC64 V CPUs. Does anyone have supportive materials (manuals, overviews, specs) about Fujitsu PP450 and SPARC64 V CPUs. Every kind of source material may be useful! All I have found from Internet, there is no Linux support

[PATCH 1/2] x86/prctl/uapi: remove ifdef for CHECKPOINT_RESTORE

As userspace knows nothing about kernel config, this ifdefs will make prctl constants invisible to userspace. Let it be clean'n'simple: remove ifdefs. If kernel has CONFIG_CHECKPOINT_RESTORE disabled, sys_prctl() will return -EINVAL for those prctls. Fixes: 2eefd8789698 ("x86/arch_prctl/vdso: Add

Re: [PATCH V4 0/5] firmware: Add support for TI System Control Interface (TI-SCI) protocol driver

On 26/10/16 22:56, Santosh Shilimkar wrote: On 10/25/2016 10:34 AM, Tero Kristo wrote: On 19/10/16 02:08, Nishanth Menon wrote: Version 4 of the series is basically a rebase to v4.9-rc1, no functional changes. Hi, Any final comments on this series, or shall I send a pull-req forward? Very

[PATCH 1/2] ARM: dts: exynos: Use macro for PWM signal polarity in Exynos4 boards

Using the PWM_POLARITY_INVERTED macro instead of the hardcoded number 0 makes the DTS easier to read. Signed-off-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos4412-odroidu3.dts | 3 ++- arch/arm/boot/dts/exynos4412-trats2.dts | 3 ++- 2 files changed, 4

Re: [PATCH V4 0/5] firmware: Add support for TI System Control Interface (TI-SCI) protocol driver

On 26/10/16 22:56, Santosh Shilimkar wrote: On 10/25/2016 10:34 AM, Tero Kristo wrote: On 19/10/16 02:08, Nishanth Menon wrote: Version 4 of the series is basically a rebase to v4.9-rc1, no functional changes. Hi, Any final comments on this series, or shall I send a pull-req forward? Very

[PATCH 1/2] ARM: dts: exynos: Use macro for PWM signal polarity in Exynos4 boards

Using the PWM_POLARITY_INVERTED macro instead of the hardcoded number 0 makes the DTS easier to read. Signed-off-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos4412-odroidu3.dts | 3 ++- arch/arm/boot/dts/exynos4412-trats2.dts | 3 ++- 2 files changed, 4 insertions(+), 2

[PATCH 2/2] ARM: dts: exynos: Use macro for PWM signal polarity in Exynos5 boards

Using the PWM_POLARITY_INVERTED macro instead of the hardcoded number 0 makes the DTS easier to read. Signed-off-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 ++- arch/arm/boot/dts/exynos5410-odroidxu.dts | 2 +-

[PATCH 2/2] ARM: dts: exynos: Use macro for PWM signal polarity in Exynos5 boards

Using the PWM_POLARITY_INVERTED macro instead of the hardcoded number 0 makes the DTS easier to read. Signed-off-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 ++- arch/arm/boot/dts/exynos5410-odroidxu.dts | 2 +-

[PATCHv3 3/8] powerpc/vdso: separate common code in vdso_common

Impact: cleanup There are common functions for handeling 32-bit and 64-bit vDSO ELF files: find_section{32,64}, find_symbol{32,64}, find_function{32,64}, vdso_do_func_patch{32,64}, vdso_do_find_sections{32,64}, vdso_fixup_datapag{32,64}, vdso_fixup_features{32,64}, vdso_setup{32,64} which all do

Re: [PATCH V4 0/5] firmware: Add support for TI System Control Interface (TI-SCI) protocol driver

On 27/10/16 19:01, Kevin Hilman wrote: Tero Kristo writes: On 19/10/16 02:08, Nishanth Menon wrote: Version 4 of the series is basically a rebase to v4.9-rc1, no functional changes. Any final comments on this series, or shall I send a pull-req forward? Very minimal changes

Re: [PATCH V4 0/5] firmware: Add support for TI System Control Interface (TI-SCI) protocol driver

On 27/10/16 19:01, Kevin Hilman wrote: Tero Kristo writes: On 19/10/16 02:08, Nishanth Menon wrote: Version 4 of the series is basically a rebase to v4.9-rc1, no functional changes. Any final comments on this series, or shall I send a pull-req forward? Very minimal changes compared to v3

[PATCHv3 3/8] powerpc/vdso: separate common code in vdso_common

Impact: cleanup There are common functions for handeling 32-bit and 64-bit vDSO ELF files: find_section{32,64}, find_symbol{32,64}, find_function{32,64}, vdso_do_func_patch{32,64}, vdso_do_find_sections{32,64}, vdso_fixup_datapag{32,64}, vdso_fixup_features{32,64}, vdso_setup{32,64} which all do

[PATCHv3 4/8] powerpc/vdso: introduce init_vdso{32,64}_pagelist

Impact: cleanup Move allocation/initialization of vDSO's pagelist for 32/64-bit vDSO into common vdso code, introducing a function for that. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Andy Lutomirski

Re: [PATCH] regulator: core: silence warning: "VDD1: ramp_delay not set"

Hi, > Am 27.10.2016 um 19:41 schrieb Matthias Kaehlcke : > > El Thu, Oct 27, 2016 at 02:31:39PM +0200 H. Nikolaus Schaller ha dit: > >> commit 73e705bf81ce ("regulator: core: Add set_voltage_time op") >> >> introduced a new rdev_warn() if the ramp_delay is 0. >> >>

Re: [PATCH] regulator: core: silence warning: "VDD1: ramp_delay not set"

Hi, > Am 27.10.2016 um 19:41 schrieb Matthias Kaehlcke : > > El Thu, Oct 27, 2016 at 02:31:39PM +0200 H. Nikolaus Schaller ha dit: > >> commit 73e705bf81ce ("regulator: core: Add set_voltage_time op") >> >> introduced a new rdev_warn() if the ramp_delay is 0. >> >> Apparently, on

[PATCHv3 4/8] powerpc/vdso: introduce init_vdso{32,64}_pagelist

Impact: cleanup Move allocation/initialization of vDSO's pagelist for 32/64-bit vDSO into common vdso code, introducing a function for that. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Andy Lutomirski Cc: Oleg Nesterov Cc: linuxppc-...@lists.ozlabs.org Cc:

[RFC v2 5/8] sched/tune: add initial support for CGroups based boosting

To support task performance boosting, the usage of a single knob has the advantage to be a simple solution, both from the implementation and the usability standpoint. However, on a real system it can be difficult to identify a single value for the knob which fits the needs of multiple different

[RFC v2 3/8] sched/fair: add function to convert boost value into "margin"

The basic idea of the boost knob is to "artificially inflate" a signal to make a task (or CPU) appears more demanding than what actually it is. Independently from the specific signal, a consistent and possibly simple semantic for the concept of "signal boosting" must define: 1. how we translate a

[RFC v2 3/8] sched/fair: add function to convert boost value into "margin"

The basic idea of the boost knob is to "artificially inflate" a signal to make a task (or CPU) appears more demanding than what actually it is. Independently from the specific signal, a consistent and possibly simple semantic for the concept of "signal boosting" must define: 1. how we translate a

[RFC v2 5/8] sched/tune: add initial support for CGroups based boosting

To support task performance boosting, the usage of a single knob has the advantage to be a simple solution, both from the implementation and the usability standpoint. However, on a real system it can be difficult to identify a single value for the knob which fits the needs of multiple different

Re: [PATCH 4/4] Input: goodix - Support interchanging x and y coordinates in hardware

On 10/27/2016 05:34 AM, Bastien Nocera wrote: > On Wed, 2016-10-26 at 18:18 -0500, Rob Herring wrote: >> On Thu, Oct 20, 2016 at 02:59:17PM -0500, Franklin S Cooper Jr wrote: >>> > >> I'm not sure I follow why existing properties don't cover this. > > Me neither. I certainly don't understand

Re: [PATCH 4/4] Input: goodix - Support interchanging x and y coordinates in hardware

On 10/27/2016 05:34 AM, Bastien Nocera wrote: > On Wed, 2016-10-26 at 18:18 -0500, Rob Herring wrote: >> On Thu, Oct 20, 2016 at 02:59:17PM -0500, Franklin S Cooper Jr wrote: >>> > >> I'm not sure I follow why existing properties don't cover this. > > Me neither. I certainly don't understand

[RFC v2 4/8] sched/fair: add boosted CPU usage

The CPU utilization signal (cpu_rq(cpu)->cfs.avg.util_avg) is used by the scheduler as an estimation of the overall bandwidth currently allocated on a CPU. When the schedutil CPUFreq governor is in use, this signal drives the selection of the Operating Performance Points (OPP) required to

[RFC v2 4/8] sched/fair: add boosted CPU usage

The CPU utilization signal (cpu_rq(cpu)->cfs.avg.util_avg) is used by the scheduler as an estimation of the overall bandwidth currently allocated on a CPU. When the schedutil CPUFreq governor is in use, this signal drives the selection of the Operating Performance Points (OPP) required to

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

On 10/27/2016 11:32 AM, Ulf Hansson wrote: [...] I'm hesistant to add a new scheduler because it's very easy to add, very difficult to get rid of. If we do add BFQ as a legacy scheduler now, it'll take us years and years to get rid of it again. We should be moving towards LESS moving parts in

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

On 10/27/2016 11:32 AM, Ulf Hansson wrote: [...] I'm hesistant to add a new scheduler because it's very easy to add, very difficult to get rid of. If we do add BFQ as a legacy scheduler now, it'll take us years and years to get rid of it again. We should be moving towards LESS moving parts in

[RFC v2 0/8] SchedTune: central, scheduler-driven, power-perfomance control

This RFC is an update to the initial SchedTune proposal [1] for a central scheduler-driven power-performance control. The posting is being made ahead of the LPC to facilitate discussions there. The initial proposal was refined, eventually merged into the AOSP, and it currently finds good use in

[RFC v2 6/8] sched/tune: compute and keep track of per CPU boost value

When per task boosting is enabled, we can have multiple RUNNABLE tasks which are concurrently scheduled on the same CPU but each one with a different boost value. For example, we could have a scenarios like this: Task SchedTune CGroup Boost Value T1 root0

[RFC v2 6/8] sched/tune: compute and keep track of per CPU boost value

When per task boosting is enabled, we can have multiple RUNNABLE tasks which are concurrently scheduled on the same CPU but each one with a different boost value. For example, we could have a scenarios like this: Task SchedTune CGroup Boost Value T1 root0

[RFC v2 0/8] SchedTune: central, scheduler-driven, power-perfomance control

This RFC is an update to the initial SchedTune proposal [1] for a central scheduler-driven power-performance control. The posting is being made ahead of the LPC to facilitate discussions there. The initial proposal was refined, eventually merged into the AOSP, and it currently finds good use in

[RFC v2 1/8] sched/tune: add detailed documentation

The topic of a single simple power-performance tunable, that is wholly scheduler centric, and has well defined and predictable properties has come up on several occasions in the past. With techniques such as a scheduler driven DVFS, which is now provided mainline via the schedutil governor, we now

Re: [PATCH] regulator: core: silence warning: "VDD1: ramp_delay not set"

El Thu, Oct 27, 2016 at 02:31:39PM +0200 H. Nikolaus Schaller ha dit: > commit 73e705bf81ce ("regulator: core: Add set_voltage_time op") > > introduced a new rdev_warn() if the ramp_delay is 0. > > Apparently, on omap3/twl4030 platforms with dynamic voltage > management this results in

[RFC v2 1/8] sched/tune: add detailed documentation

The topic of a single simple power-performance tunable, that is wholly scheduler centric, and has well defined and predictable properties has come up on several occasions in the past. With techniques such as a scheduler driven DVFS, which is now provided mainline via the schedutil governor, we now

Re: [PATCH] regulator: core: silence warning: "VDD1: ramp_delay not set"

El Thu, Oct 27, 2016 at 02:31:39PM +0200 H. Nikolaus Schaller ha dit: > commit 73e705bf81ce ("regulator: core: Add set_voltage_time op") > > introduced a new rdev_warn() if the ramp_delay is 0. > > Apparently, on omap3/twl4030 platforms with dynamic voltage > management this results in

[RFC v2 2/8] sched/tune: add sysctl interface to define a boost value

The current (CFS) scheduler implementation does not allow "to boost" tasks performance by running them at a higher OPP compared to the minimum required to meet their workload demands. To support tasks performance boosting the scheduler should provide a "knob" which allows to tune how much the

[RFC v2 2/8] sched/tune: add sysctl interface to define a boost value

The current (CFS) scheduler implementation does not allow "to boost" tasks performance by running them at a higher OPP compared to the minimum required to meet their workload demands. To support tasks performance boosting the scheduler should provide a "knob" which allows to tune how much the

[RFC v2 7/8] sched/{fair,tune}: track RUNNABLE tasks impact on per CPU boost value

When per-task boosting is enabled, every time a task enters/exits a CPU its boost value could impact the currently selected OPP for that CPU. Thus, the "aggregated" boost value for that CPU potentially needs to be updated to match the current maximum boost value among all the tasks currently

Re: [PATCH 2/4] Input: goodix - Allow tweaking of configuration file dynamically

On Thu, 2016-10-27 at 11:58 -0500, Franklin S Cooper Jr wrote: > > On 10/27/2016 05:33 AM, Bastien Nocera wrote: > > On Thu, 2016-10-20 at 14:59 -0500, Franklin S Cooper Jr wrote: > > > Some goodix touchscreen controllers don't have the correct > > > configuration > > > firmware for the display

[RFC v2 8/8] sched/{fair,tune}: add support for negative boosting

Boosting support allows to inflate a signal with a margin which is defined to be proportional to its delta from its maximum possible value. Such a mechanism allows to run a task on an OPP which is higher with respect to the minimum capacity which can satisfy its demands. In certain use-cases we

[RFC v2 7/8] sched/{fair,tune}: track RUNNABLE tasks impact on per CPU boost value

When per-task boosting is enabled, every time a task enters/exits a CPU its boost value could impact the currently selected OPP for that CPU. Thus, the "aggregated" boost value for that CPU potentially needs to be updated to match the current maximum boost value among all the tasks currently

Re: [PATCH 2/4] Input: goodix - Allow tweaking of configuration file dynamically

On Thu, 2016-10-27 at 11:58 -0500, Franklin S Cooper Jr wrote: > > On 10/27/2016 05:33 AM, Bastien Nocera wrote: > > On Thu, 2016-10-20 at 14:59 -0500, Franklin S Cooper Jr wrote: > > > Some goodix touchscreen controllers don't have the correct > > > configuration > > > firmware for the display

[RFC v2 8/8] sched/{fair,tune}: add support for negative boosting

Boosting support allows to inflate a signal with a margin which is defined to be proportional to its delta from its maximum possible value. Such a mechanism allows to run a task on an OPP which is higher with respect to the minimum capacity which can satisfy its demands. In certain use-cases we

Re: [PATCH 2/2] serial: 8250_dw: Add support for IrDA SIR mode

On 10/27/16 17:56, Andy Shevchenko wrote: On Thu, 2016-10-27 at 17:38 +0100, Ed Blake wrote: Add a set_ldisc function to enable/disable IrDA SIR mode according to the new line discipline. Thanks for the patch. Consider that not all implementations based on 8250_dw support IRDA feature. I

Re: [PATCH 2/2] serial: 8250_dw: Add support for IrDA SIR mode

On 10/27/16 17:56, Andy Shevchenko wrote: On Thu, 2016-10-27 at 17:38 +0100, Ed Blake wrote: Add a set_ldisc function to enable/disable IrDA SIR mode according to the new line discipline. Thanks for the patch. Consider that not all implementations based on 8250_dw support IRDA feature. I

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

[...] > > I'm hesistant to add a new scheduler because it's very easy to add, very > difficult to get rid of. If we do add BFQ as a legacy scheduler now, > it'll take us years and years to get rid of it again. We should be > moving towards LESS moving parts in the legacy path, not more. Jens, I

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

[...] > > I'm hesistant to add a new scheduler because it's very easy to add, very > difficult to get rid of. If we do add BFQ as a legacy scheduler now, > it'll take us years and years to get rid of it again. We should be > moving towards LESS moving parts in the legacy path, not more. Jens, I

Re: [RFC PATCH 0/5] Add an overlay manager to handle board capes

On Thu, Oct 27, 2016 at 10:13 AM, Hans de Goede wrote: > Hi, > > On 27-10-16 15:41, Rob Herring wrote: >> >> Please Cc the maintainers of drivers/of/. >> >> + Frank R, Hans, Dmitry S >> >> On Wed, Oct 26, 2016 at 9:57 AM, Antoine Tenart >>

Re: [RFC PATCH 0/5] Add an overlay manager to handle board capes

On Thu, Oct 27, 2016 at 10:13 AM, Hans de Goede wrote: > Hi, > > On 27-10-16 15:41, Rob Herring wrote: >> >> Please Cc the maintainers of drivers/of/. >> >> + Frank R, Hans, Dmitry S >> >> On Wed, Oct 26, 2016 at 9:57 AM, Antoine Tenart >> wrote: >>> >>> Hi all, >>> >>> Many boards now come with

Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]

On Tue, Aug 09, 2016 at 08:20:57PM +0300, Ville Syrjälä wrote: > On Thu, Jul 14, 2016 at 04:29:42PM +0800, Feng Tang wrote: > > if you only want it to work, you can try an old patch > > https://bugzilla.kernel.org/attachment.cgi?id=76071 from a similar bug > >

Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]

On Tue, Aug 09, 2016 at 08:20:57PM +0300, Ville Syrjälä wrote: > On Thu, Jul 14, 2016 at 04:29:42PM +0800, Feng Tang wrote: > > if you only want it to work, you can try an old patch > > https://bugzilla.kernel.org/attachment.cgi?id=76071 from a similar bug > >

[PATCH] drivers/platform/x86: fix semicolon.cocci warnings

drivers/platform/x86/mlx-platform.c:219:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Vadim Pasternak Signed-off-by: Fengguang Wu --- mlx-platform.c |2 +- 1 file changed, 1

[PATCH] drivers/platform/x86: fix semicolon.cocci warnings

drivers/platform/x86/mlx-platform.c:219:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Vadim Pasternak Signed-off-by: Fengguang Wu --- mlx-platform.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ---

Re: [patch v1 1/2] drivers/platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86

Hi Vadim, [auto build test WARNING on platform-drivers-x86/for-next] [also build test WARNING on next-20161027] [cannot apply to v4.9-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --b

Re: [patch v1 1/2] drivers/platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86

Hi Vadim, [auto build test WARNING on platform-drivers-x86/for-next] [also build test WARNING on next-20161027] [cannot apply to v4.9-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --b

Re: [PATCH 4.4 000/112] 4.4.28-stable review

On Thu, Oct 27, 2016 at 10:12:21AM -0700, Kevin Hilman wrote: > These are QEMU jobs that the test framework (LAVA) is not waiting long > enough to finish. When run standalone, the QEMU tests are passing. Lab > owner is looking into it. I *think* the timeouts come from the LAVA jobs rather than

Re: [PATCH 4.4 000/112] 4.4.28-stable review

On Thu, Oct 27, 2016 at 10:12:21AM -0700, Kevin Hilman wrote: > These are QEMU jobs that the test framework (LAVA) is not waiting long > enough to finish. When run standalone, the QEMU tests are passing. Lab > owner is looking into it. I *think* the timeouts come from the LAVA jobs rather than

Re: bio linked list corruption.

On Thu, Oct 27, 2016 at 04:41:33PM +1100, Dave Chinner wrote: > And that's indicative of a delalloc metadata reservation being > being too small and so we're allocating unreserved blocks. > > Different symptoms, same underlying cause, I think. > > I see the latter assert from time to

Re: bio linked list corruption.

On Thu, Oct 27, 2016 at 04:41:33PM +1100, Dave Chinner wrote: > And that's indicative of a delalloc metadata reservation being > being too small and so we're allocating unreserved blocks. > > Different symptoms, same underlying cause, I think. > > I see the latter assert from time to

Re: Build regressions/improvements in v4.9-rc1

+CC Claudiu On 10/27/2016 02:39 AM, Alexey Brodkin wrote: > > And these are functions required by U-Boot (most probably the same is applied > to kernel): > 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX This kicks in only at -Os and even there can be inhibited with a toggle. I

Re: Build regressions/improvements in v4.9-rc1

+CC Claudiu On 10/27/2016 02:39 AM, Alexey Brodkin wrote: > > And these are functions required by U-Boot (most probably the same is applied > to kernel): > 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX This kicks in only at -Os and even there can be inhibited with a toggle. I

Re: [PATCH v2 0/3] usb: musb: da8xx: Fix few issues

On 10/26/2016 05:58 AM, Alexandre Bailon wrote: Currently, the USB OTG of the da8xx doesn't work. This series intend to fix them. Change in v2: * Fix the error path da8xx_musb_init() Alexandre Bailon (3): usb: musb: da8xx: Call earlier clk_prepare_enable() phy: da8xx-usb: Configure

Re: [PATCH v2 0/3] usb: musb: da8xx: Fix few issues

On 10/26/2016 05:58 AM, Alexandre Bailon wrote: Currently, the USB OTG of the da8xx doesn't work. This series intend to fix them. Change in v2: * Fix the error path da8xx_musb_init() Alexandre Bailon (3): usb: musb: da8xx: Call earlier clk_prepare_enable() phy: da8xx-usb: Configure

Re: [PATCH 0/7] powerpc/mm: refactor vDSO mapping code

2016-10-25 18:50 GMT+03:00 Dmitry Safonov : > Cleanup patches for vDSO on powerpc. > Originally, I wanted to add vDSO remapping on arm/aarch64 and > I decided to cleanup that part on powerpc. > I've add a hook for vm_ops for vDSO just like I did for x86. > Other changes -

Re: [PATCH 0/7] powerpc/mm: refactor vDSO mapping code

2016-10-25 18:50 GMT+03:00 Dmitry Safonov : > Cleanup patches for vDSO on powerpc. > Originally, I wanted to add vDSO remapping on arm/aarch64 and > I decided to cleanup that part on powerpc. > I've add a hook for vm_ops for vDSO just like I did for x86. > Other changes - reduce exhaustive code

[PATCH 1/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5250 Snow board

There's a cognitive load to figure out which mmc device node corresponds to the eMMC flash, uSD card and WiFI SDIO module on the Snow boards. So it's better to have comments in the DTS to make this more clear. Signed-off-by: Javier Martinez Canillas ---

[PATCH 3/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5800 Peach Pi board

There's a cognitive load to figure out which mmc device nodes corresponds to the eMMC flash, uSD card and WiFI SDIO module on the Peach Pi board. So it's better to have comments in the DTS to make this more clear. Signed-off-by: Javier Martinez Canillas ---

[PATCH 1/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5250 Snow board

There's a cognitive load to figure out which mmc device node corresponds to the eMMC flash, uSD card and WiFI SDIO module on the Snow boards. So it's better to have comments in the DTS to make this more clear. Signed-off-by: Javier Martinez Canillas ---

[PATCH 3/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5800 Peach Pi board

There's a cognitive load to figure out which mmc device nodes corresponds to the eMMC flash, uSD card and WiFI SDIO module on the Peach Pi board. So it's better to have comments in the DTS to make this more clear. Signed-off-by: Javier Martinez Canillas ---

[PATCH 2/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5420 Pit board

There's a cognitive load to figure out which mmc device nodes corresponds to the eMMC flash, uSD card and WiFI SDIO module on the Peach Pit board. So it's better to have comments in the DTS to make this more clear. Signed-off-by: Javier Martinez Canillas ---

[PATCH 2/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5420 Pit board

There's a cognitive load to figure out which mmc device nodes corresponds to the eMMC flash, uSD card and WiFI SDIO module on the Peach Pit board. So it's better to have comments in the DTS to make this more clear. Signed-off-by: Javier Martinez Canillas ---

Re: [PATCH V3 5/6] ARM: tegra: Add Tegra20 GMI support

Hi Mirza, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.9-rc2 next-20161027] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

Re: [PATCH V3 5/6] ARM: tegra: Add Tegra20 GMI support

Hi Mirza, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.9-rc2 next-20161027] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

<    3   4   5   6   7   8   9   10   11   12   >