On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote:
> Hi Peter,
>
> Unfortunately I can't apply this on top of our drm-next the first patch
> fails.
Against what tree would you like the patches? rebasing should not be
hard I think.
On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote:
> Hi Peter,
>
> Unfortunately I can't apply this on top of our drm-next the first patch
> fails.
Against what tree would you like the patches? rebasing should not be
hard I think.
When we have KCOV enabled and running ftrace startup tests we end up in
a softlockup. Kcov and ftrace tracing each other makes it really slow:
[ 275.141388] Testing tracer wakeup_dl: PASSED
[ 304.738345] Testing tracer function_graph:
[ 716.236822] watchdog: BUG: soft lockup - CPU#0 stuck for
When we have KCOV enabled and running ftrace startup tests we end up in
a softlockup. Kcov and ftrace tracing each other makes it really slow:
[ 275.141388] Testing tracer wakeup_dl: PASSED
[ 304.738345] Testing tracer function_graph:
[ 716.236822] watchdog: BUG: soft lockup - CPU#0 stuck for
Function graph tracing recurses into itself when stackleak is enabled,
causing the ftrace graph selftest to run for up to 90 seconds and
trigger the softlockup watchdog.
Breakpoint 2, ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:200
200 mcount_get_lr_addrx0
Function graph tracing recurses into itself when stackleak is enabled,
causing the ftrace graph selftest to run for up to 90 seconds and
trigger the softlockup watchdog.
Breakpoint 2, ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:200
200 mcount_get_lr_addrx0
On 2018-11-30 10:07 a.m., Deucher, Alexander wrote:
> Sure, but it might be week or so. For now can you test against Linus
> master? It should be close enough.
I need the bulk move from the our drm-next merge (which isn't yet
upstream) to trigger the bug though.
I can try to cherry pick it
On 2018-11-30 10:07 a.m., Deucher, Alexander wrote:
> Sure, but it might be week or so. For now can you test against Linus
> master? It should be close enough.
I need the bulk move from the our drm-next merge (which isn't yet
upstream) to trigger the bug though.
I can try to cherry pick it
On Fri, Nov 30, 2018 at 4:01 PM Srinivas Kandagatla
wrote:
> Thanks Arnd for the review comments!
> On 30/11/18 13:41, Arnd Bergmann wrote:
> > On Fri, Nov 30, 2018 at 11:48 AM Srinivas Kandagatla
> > wrote:
> >> +static long fastrpc_device_ioctl(struct file *file, unsigned int cmd,
> >> +
On Fri, Nov 30, 2018 at 4:01 PM Srinivas Kandagatla
wrote:
> Thanks Arnd for the review comments!
> On 30/11/18 13:41, Arnd Bergmann wrote:
> > On Fri, Nov 30, 2018 at 11:48 AM Srinivas Kandagatla
> > wrote:
> >> +static long fastrpc_device_ioctl(struct file *file, unsigned int cmd,
> >> +
On 30 November 2018 12:47:52 PM IST, Greg Kroah-Hartman
wrote:
>On Fri, Nov 30, 2018 at 03:54:48AM +0530, Harsh Shandilya wrote:
>> On 29 November 2018 7:41:31 PM IST, Greg Kroah-Hartman
> wrote:
>> >This is the start of the stable review cycle for the 4.19.6 release.
>> >There are 110 patches
On 30 November 2018 12:47:52 PM IST, Greg Kroah-Hartman
wrote:
>On Fri, Nov 30, 2018 at 03:54:48AM +0530, Harsh Shandilya wrote:
>> On 29 November 2018 7:41:31 PM IST, Greg Kroah-Hartman
> wrote:
>> >This is the start of the stable review cycle for the 4.19.6 release.
>> >There are 110 patches
Hi Chris,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc4 next-20181130]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Chris,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc4 next-20181130]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
The below issues are found in the recent testing.
1. Observed device is not going into off state or not responding.
As wcn3990 require a power pulses to turn on the irrespctive of
igniting regulators, it was observed that power on or power off
pulses are not in sync with respective to
The below issues are found in the recent testing.
1. Observed device is not going into off state or not responding.
As wcn3990 require a power pulses to turn on the irrespctive of
igniting regulators, it was observed that power on or power off
pulses are not in sync with respective to
During hci down we observed IBS sleep commands are queued in the Tx
buffer and hci_uart_write_work is sending data to the chip which is
not required as the chip is powered off. This patch will disable IBS
and flush the Tx buffer before we turn off the chip.
Signed-off-by: Balakrishna Godavarthi
During hci down we observed IBS sleep commands are queued in the Tx
buffer and hci_uart_write_work is sending data to the chip which is
not required as the chip is powered off. This patch will disable IBS
and flush the Tx buffer before we turn off the chip.
Signed-off-by: Balakrishna Godavarthi
During initalization of wcn3990, we observed UART is reading some
stray bytes on the Rx line. This is logging Frame reassembly errors
on the serial console. This could be because of tristate of Tx line
of wcn3990 during boot up.
[ 176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame
wcn3990 requires a power pulse to turn ON/OFF along with
regulators. Sometimes we are observing the power pulses are sent
out with some time delay, due to queuing these commands. This is
causing synchronization issues with chip, which intern delay the
chip setup or may end up with communication
During initalization of wcn3990, we observed UART is reading some
stray bytes on the Rx line. This is logging Frame reassembly errors
on the serial console. This could be because of tristate of Tx line
of wcn3990 during boot up.
[ 176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame
wcn3990 requires a power pulse to turn ON/OFF along with
regulators. Sometimes we are observing the power pulses are sent
out with some time delay, due to queuing these commands. This is
causing synchronization issues with chip, which intern delay the
chip setup or may end up with communication
This patch will help to stop frame reassembly errors while changing
the baudrate. This is because host send a change baudrate request
command to the chip with 115200 bps, Whereas chip will change their
UART clocks to the enable for new baudrate and sends the response
for the change request command
This patch will help to stop frame reassembly errors while changing
the baudrate. This is because host send a change baudrate request
command to the chip with 115200 bps, Whereas chip will change their
UART clocks to the enable for new baudrate and sends the response
for the change request command
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 6ebbd5010722..782cc33916d6 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 6ebbd5010722..782cc33916d6 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++
Thanks Arnd for the review comments!
On 30/11/18 13:41, Arnd Bergmann wrote:
On Fri, Nov 30, 2018 at 11:48 AM Srinivas Kandagatla
wrote:
This patch adds support to compute context invoke method
on the remote processor (DSP).
This involves setting up the functions input and output arguments,
Thanks Arnd for the review comments!
On 30/11/18 13:41, Arnd Bergmann wrote:
On Fri, Nov 30, 2018 at 11:48 AM Srinivas Kandagatla
wrote:
This patch adds support to compute context invoke method
on the remote processor (DSP).
This involves setting up the functions input and output arguments,
When building a allmodconfig kernel for arm64 and boot that in qemu,
CONFIG_FTRACE_STARTUP_TEST gets enabled and that takes time so the
watchdog expires and prints out a message like this:
'watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1]'
Depending on what the what test gets called
When building a allmodconfig kernel for arm64 and boot that in qemu,
CONFIG_FTRACE_STARTUP_TEST gets enabled and that takes time so the
watchdog expires and prints out a message like this:
'watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1]'
Depending on what the what test gets called
On Fri, Nov 30, 2018 at 09:24:54AM +0800, Chao Fan wrote:
> On Thu, Nov 29, 2018 at 12:55:21PM -0500, Masayoshi Mizuma wrote:
> >On Thu, Nov 29, 2018 at 04:16:30PM +0800, Chao Fan wrote:
> >> To fix the conflict between KASLR and memory-hotremove, SRAT table
> >> should be parsed by RSDP pointer,
On Fri, Nov 30, 2018 at 09:24:54AM +0800, Chao Fan wrote:
> On Thu, Nov 29, 2018 at 12:55:21PM -0500, Masayoshi Mizuma wrote:
> >On Thu, Nov 29, 2018 at 04:16:30PM +0800, Chao Fan wrote:
> >> To fix the conflict between KASLR and memory-hotremove, SRAT table
> >> should be parsed by RSDP pointer,
Hi Peter,
Unfortunately I can't apply this on top of our drm-next the first patch
fails.
Alex: could we rebase again at some point?
Tom
On 2018-11-30 8:44 a.m., Peter Zijlstra wrote:
> Hi,
>
> Yesterday Tom reported a CPA bug triggered by the AMDGPU team.
>
> It turns out that with commit:
Hi Peter,
Unfortunately I can't apply this on top of our drm-next the first patch
fails.
Alex: could we rebase again at some point?
Tom
On 2018-11-30 8:44 a.m., Peter Zijlstra wrote:
> Hi,
>
> Yesterday Tom reported a CPA bug triggered by the AMDGPU team.
>
> It turns out that with commit:
On 30/11/2018 5:40 am, Stephen Rothwell wrote:
> After merging the akpm tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> lib/lzo/lzo1x_compress.c: In function 'lzo1x_1_do_compress':
> lib/lzo/lzo1x_compress.c:239:14: warning: 'm_pos' may be used uninitialized
>
On 30/11/2018 5:40 am, Stephen Rothwell wrote:
> After merging the akpm tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> lib/lzo/lzo1x_compress.c: In function 'lzo1x_1_do_compress':
> lib/lzo/lzo1x_compress.c:239:14: warning: 'm_pos' may be used uninitialized
>
Hi,
Some folks have reported on the Fedora bug tracker[0] that the laptop
speaker volume is very low on the Thinkpad T570 when running a kernel
that includes commit 61fcf8ece9b6 ("ALSA: hda/realtek - Enable Thinkpad
Dock device for ALC298 platform").
alsa-info.sh from v4.15.4 (just before commit
Hi,
Some folks have reported on the Fedora bug tracker[0] that the laptop
speaker volume is very low on the Thinkpad T570 when running a kernel
that includes commit 61fcf8ece9b6 ("ALSA: hda/realtek - Enable Thinkpad
Dock device for ALC298 platform").
alsa-info.sh from v4.15.4 (just before commit
From: Grzegorz Jaszczyk
Add SATA mode to the PHY framework in preparation of upcoming PHYs
that will handle it. For instance, SATA mode will be used by the
Armada3700 COMPHY driver, which supports configuring SERDES lanes to
be used by various controllers: Ethernet, USB3, SATA and PCIe.
From: Grzegorz Jaszczyk
Add SATA mode to the PHY framework in preparation of upcoming PHYs
that will handle it. For instance, SATA mode will be used by the
Armada3700 COMPHY driver, which supports configuring SERDES lanes to
be used by various controllers: Ethernet, USB3, SATA and PCIe.
Current file describe COMPHY bindings for the IP available on the
CP110 of Armada 7k/8k. Bindings are very close (and serve the same
purpose) as the new Armada 3700 COMPHY driver so update this file to
describe both. Also add an example of how to use this second
compatible (same as for the
Add a driver to support COMPHY, a hardware block providing shared
serdes PHYs on Marvell Armada 3700. This driver uses SMC calls and
rely on having an up-to-date firmware.
SATA, PCie and USB3 host mode have been tested successfully with an
ESPRESSObin. SGMII mode cannot be tested with this
Fix the SATA IP memory area which is only 0x178 bytes long (from
Marvell A3700 specification). Actually, starting from the offset
0xe0178, there is an area dedicated to the COMPHY driver.
Suggested-by: Grzegorz Jaszczyk
Signed-off-by: Miquel Raynal
---
Describe the A3700 COMPHY node. It has three PHYs that can be
configured as follow:
* PCIe or GbE
* USB3 or GbE
* SATA or USB3
Each of them has its own memory area.
Suggested-by: Grzegorz Jaszczyk
Signed-off-by: Miquel Raynal
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 29
Luis Chamberlain writes:
> On Mon, Nov 26, 2018 at 11:29:40PM -0600, Eric W. Biederman wrote:
>> Luis Chamberlain writes:
>> > Thanks for the description of how to run into the issue described but
>> > is there also a practical use case today where this is happening? I ask
>> > as it would be
Current file describe COMPHY bindings for the IP available on the
CP110 of Armada 7k/8k. Bindings are very close (and serve the same
purpose) as the new Armada 3700 COMPHY driver so update this file to
describe both. Also add an example of how to use this second
compatible (same as for the
Add a driver to support COMPHY, a hardware block providing shared
serdes PHYs on Marvell Armada 3700. This driver uses SMC calls and
rely on having an up-to-date firmware.
SATA, PCie and USB3 host mode have been tested successfully with an
ESPRESSObin. SGMII mode cannot be tested with this
Fix the SATA IP memory area which is only 0x178 bytes long (from
Marvell A3700 specification). Actually, starting from the offset
0xe0178, there is an area dedicated to the COMPHY driver.
Suggested-by: Grzegorz Jaszczyk
Signed-off-by: Miquel Raynal
---
Describe the A3700 COMPHY node. It has three PHYs that can be
configured as follow:
* PCIe or GbE
* USB3 or GbE
* SATA or USB3
Each of them has its own memory area.
Suggested-by: Grzegorz Jaszczyk
Signed-off-by: Miquel Raynal
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 29
Luis Chamberlain writes:
> On Mon, Nov 26, 2018 at 11:29:40PM -0600, Eric W. Biederman wrote:
>> Luis Chamberlain writes:
>> > Thanks for the description of how to run into the issue described but
>> > is there also a practical use case today where this is happening? I ask
>> > as it would be
So far the PHY ->xlate() callback was checking if the port was
"invalid" before continuing, meaning that the port has not been used
yet. This check is not correct as there is no opposite call to
->xlate() once the PHY is released by the user and the port will
remain "valid" after the first
Add myself as Armada 3700 COMPHY driver/bindings maintainer.
Signed-off-by: Miquel Raynal
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f4855974f325..a1d6457cccb5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8864,6 +8864,12 @@ F:
Hello,
This series adds a new driver to support Armada 3700 COMPHY IP.
The series has been tested on an ESPRESSObin with SATA, PCIe
and USB3 host. For this purpose, patch 1 enumerates the SATA PHY
mode. The SGMII PHY mode that is supported by the IP has been written
(uses SMC calls anyway) but
So far the PHY ->xlate() callback was checking if the port was
"invalid" before continuing, meaning that the port has not been used
yet. This check is not correct as there is no opposite call to
->xlate() once the PHY is released by the user and the port will
remain "valid" after the first
Add myself as Armada 3700 COMPHY driver/bindings maintainer.
Signed-off-by: Miquel Raynal
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f4855974f325..a1d6457cccb5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8864,6 +8864,12 @@ F:
Hello,
This series adds a new driver to support Armada 3700 COMPHY IP.
The series has been tested on an ESPRESSObin with SATA, PCIe
and USB3 host. For this purpose, patch 1 enumerates the SATA PHY
mode. The SGMII PHY mode that is supported by the IP has been written
(uses SMC calls anyway) but
Rename the mvebu_comhy_conf structure to be mvebu_comphy_conf, which is
probably what the original author meant.
Signed-off-by: Miquel Raynal
---
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Rename the mvebu_comhy_conf structure to be mvebu_comphy_conf, which is
probably what the original author meant.
Signed-off-by: Miquel Raynal
---
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Fri, 30 Nov 2018 15:01:58 +0100
Jiri Olsa wrote:
> > or perhaps just tracepoints.. does not seem to make much
> > sense for he events
>
> actualy the syscalls seems to be enough for now ;-) I tried
> something and ended up with hack below
Actually, we *only* want to do syscalls. We really
On Fri, 30 Nov 2018 15:01:58 +0100
Jiri Olsa wrote:
> > or perhaps just tracepoints.. does not seem to make much
> > sense for he events
>
> actualy the syscalls seems to be enough for now ;-) I tried
> something and ended up with hack below
Actually, we *only* want to do syscalls. We really
Le mer. 14 nov. 2018 à 10:00, Benjamin Gaignard
a écrit :
>
> This serie adds the support of the hardware semaphore block for stm32mp1 SoC.
>
> version 4:
> - add Linaro SoB
Gentle ping on this series
Regards,
Benjamin
>
> version 3:
> - fix clock name in properties description.
> - use
Le mer. 14 nov. 2018 à 10:00, Benjamin Gaignard
a écrit :
>
> This serie adds the support of the hardware semaphore block for stm32mp1 SoC.
>
> version 4:
> - add Linaro SoB
Gentle ping on this series
Regards,
Benjamin
>
> version 3:
> - fix clock name in properties description.
> - use
On Fri, Nov 30, 2018 at 08:03:38AM +, He, Bo wrote:
> Thanks for your great suggestions.
> After enable the CONFIG_RCU_BOOST=y, we don't reproduce the issue until now,
> we will keep it running and update you with the test results.
>
> The enclosed is the kernel config, here is the config I
On Fri, Nov 30, 2018 at 08:03:38AM +, He, Bo wrote:
> Thanks for your great suggestions.
> After enable the CONFIG_RCU_BOOST=y, we don't reproduce the issue until now,
> we will keep it running and update you with the test results.
>
> The enclosed is the kernel config, here is the config I
On 30/11/18 4:13 PM, Du, Alek wrote:
> On Fri, 30 Nov 2018 11:19:03 +0200
> Adrian Hunter wrote:
>
>> Commands and resets are under spin lock, so no possibility for
>> preemption, and certainly a few microseconds isn't going to make any
>> difference to these timeouts, so I don't see how this
On 30/11/18 4:13 PM, Du, Alek wrote:
> On Fri, 30 Nov 2018 11:19:03 +0200
> Adrian Hunter wrote:
>
>> Commands and resets are under spin lock, so no possibility for
>> preemption, and certainly a few microseconds isn't going to make any
>> difference to these timeouts, so I don't see how this
On Tue, Nov 27, 2018 at 2:38 PM Jacek Anaszewski
wrote:
>
> On 11/13/2018 09:57 PM, Jacek Anaszewski wrote:
> > On 11/12/2018 07:27 PM, Rob Herring wrote:
> >> On Tue, Nov 06, 2018 at 11:07:12PM +0100, Jacek Anaszewski wrote:
> >>> Introduce dedicated properties for conveying information about
>
On 11/29/2018 05:48 PM, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 05:41:35PM -0500, Waiman Long wrote:
>> When a kernel module is repeatedly load and unload, it will eventually
>> exhaust the lockdep entries resulting in a bug message. This is a use
>> case that the current lockdep code
On Tue, Nov 27, 2018 at 2:38 PM Jacek Anaszewski
wrote:
>
> On 11/13/2018 09:57 PM, Jacek Anaszewski wrote:
> > On 11/12/2018 07:27 PM, Rob Herring wrote:
> >> On Tue, Nov 06, 2018 at 11:07:12PM +0100, Jacek Anaszewski wrote:
> >>> Introduce dedicated properties for conveying information about
>
On 11/29/2018 05:48 PM, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 05:41:35PM -0500, Waiman Long wrote:
>> When a kernel module is repeatedly load and unload, it will eventually
>> exhaust the lockdep entries resulting in a bug message. This is a use
>> case that the current lockdep code
On 2018/11/30 21:30, Petr Mladek wrote:
> I am not fully happy with the solution passing time parameter.
> It is less secure. But it would not break compatibility.
> This particular race might be solved the following way:
>
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index
On 2018/11/30 21:30, Petr Mladek wrote:
> I am not fully happy with the solution passing time parameter.
> It is less secure. But it would not break compatibility.
> This particular race might be solved the following way:
>
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index
On Thu, Nov 29, 2018 at 10:31 PM Loic Pallardy wrote:
>
> Today resource table supports only 32bit address fields.
> This is not compliant with 64bit platform for which addresses
> are cast in 32bit.
> This patch adds warn messages when address cast is done.
>
> Signed-off-by: Loic Pallardy
>
On Thu, Nov 29, 2018 at 10:31 PM Loic Pallardy wrote:
>
> Today resource table supports only 32bit address fields.
> This is not compliant with 64bit platform for which addresses
> are cast in 32bit.
> This patch adds warn messages when address cast is done.
>
> Signed-off-by: Loic Pallardy
>
From: Matt Sealey
Enable faster 8-byte copies on arm64.
Link: http://lkml.kernel.org/r/20181127161913.23863-6-dave.rodg...@arm.com
Signed-off-by: Matt Sealey
Signed-off-by: Dave Rodgman
Cc: David S. Miller
Cc: Greg Kroah-Hartman
Cc: Herbert Xu
Cc: Markus F.X.J. Oberhumer
Cc: Minchan Kim
From: Matt Sealey
Enable faster 8-byte copies on arm64.
Link: http://lkml.kernel.org/r/20181127161913.23863-6-dave.rodg...@arm.com
Signed-off-by: Matt Sealey
Signed-off-by: Dave Rodgman
Cc: David S. Miller
Cc: Greg Kroah-Hartman
Cc: Herbert Xu
Cc: Markus F.X.J. Oberhumer
Cc: Minchan Kim
lzo-rle gives higher performance and similar compression ratios to lzo.
Testing with 80 browser tabs showed a 27% reduction in total time spent
(de)compressing data during swapping.
Signed-off-by: Dave Rodgman
---
drivers/block/zram/zram_drv.c | 2 +-
1 file changed, 1 insertion(+), 1
lzo-rle gives higher performance and similar compression ratios to lzo.
Testing with 80 browser tabs showed a 27% reduction in total time spent
(de)compressing data during swapping.
Signed-off-by: Dave Rodgman
---
drivers/block/zram/zram_drv.c | 2 +-
1 file changed, 1 insertion(+), 1
To prevent any issues with persistent data, separate lzo-rle
from lzo so that it is treated as a separate algorithm, and
lzo is still available.
Link: http://lkml.kernel.org/r/20181127161913.23863-8-dave.rodg...@arm.com
Signed-off-by: Dave Rodgman
Cc: David S. Miller
Cc: Greg Kroah-Hartman
Cc:
From: Matt Sealey
ARMv6 Thumb state introduced an RBIT instruction which, combined with CLZ
as present in ARMv5, introduces an extremely fast path for counting
trailing zeroes.
Enable the use of the GCC builtin for this on ARMv6+ with
CONFIG_THUMB2_KERNEL to ensure we get the 'new' instruction
When using zram, we frequently encounter long runs of zero bytes.
This adds a special case which identifies runs of zeros and encodes
them using run-length encoding.
This is faster for both compression and decompresion. For
high-entropy data which doesn't hit this case, impact is minimal.
To prevent any issues with persistent data, separate lzo-rle
from lzo so that it is treated as a separate algorithm, and
lzo is still available.
Link: http://lkml.kernel.org/r/20181127161913.23863-8-dave.rodg...@arm.com
Signed-off-by: Dave Rodgman
Cc: David S. Miller
Cc: Greg Kroah-Hartman
Cc:
From: Matt Sealey
ARMv6 Thumb state introduced an RBIT instruction which, combined with CLZ
as present in ARMv5, introduces an extremely fast path for counting
trailing zeroes.
Enable the use of the GCC builtin for this on ARMv6+ with
CONFIG_THUMB2_KERNEL to ensure we get the 'new' instruction
When using zram, we frequently encounter long runs of zero bytes.
This adds a special case which identifies runs of zeros and encodes
them using run-length encoding.
This is faster for both compression and decompresion. For
high-entropy data which doesn't hit this case, impact is minimal.
This patch series introduces performance improvements for lzo.
The previous version of this patchset is here:
https://lkml.org/lkml/2018/11/30/807
This version of the patchset fixes a maybe-used-uninitialized warning
(although the previous version was still safe).
Dave
Modify the ifdefs in lzodefs.h to be more consistent with normal kernel
macros (e.g., change __aarch64__ to CONFIG_ARM64).
Signed-off-by: Dave Rodgman
Cc: Herbert Xu
Cc: David S. Miller
Cc: Nitin Gupta
Cc: Richard Purdie
Cc: Markus F.X.J. Oberhumer
Cc: Minchan Kim
Cc: Sergey Senozhatsky
This patch series introduces performance improvements for lzo.
The previous version of this patchset is here:
https://lkml.org/lkml/2018/11/30/807
This version of the patchset fixes a maybe-used-uninitialized warning
(although the previous version was still safe).
Dave
Modify the ifdefs in lzodefs.h to be more consistent with normal kernel
macros (e.g., change __aarch64__ to CONFIG_ARM64).
Signed-off-by: Dave Rodgman
Cc: Herbert Xu
Cc: David S. Miller
Cc: Nitin Gupta
Cc: Richard Purdie
Cc: Markus F.X.J. Oberhumer
Cc: Minchan Kim
Cc: Sergey Senozhatsky
On Fri, Nov 30, 2018 at 02:44:54PM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
>
> > On Fri, Nov 30, 2018 at 01:15:11PM +0100, Vitaly Kuznetsov wrote:
> >> Without 'packed' compiler is free to add optimization paddings and re-order
> >> structure fields for randomization/optimization.
From: Matt Sealey
Most compilers should be able to merge adjacent loads/stores of sizes
which are less than but effect a multiple of a machine word size (in
effect a memcpy() of a constant amount). However the semantics of the
macro are that it just does the copy, the pointer increment is in the
From: Matt Sealey
LZO leaves some performance on the table by not realising that arm64 can
optimize count-trailing-zeros bit operations.
Add CONFIG_ARM64 to the checked definitions alongside CONFIG_X86_64 to
enable the use of rbit/clz instructions on full 64-bit quantities.
Link:
From: Matt Sealey
Most compilers should be able to merge adjacent loads/stores of sizes
which are less than but effect a multiple of a machine word size (in
effect a memcpy() of a constant amount). However the semantics of the
macro are that it just does the copy, the pointer increment is in the
From: Matt Sealey
LZO leaves some performance on the table by not realising that arm64 can
optimize count-trailing-zeros bit operations.
Add CONFIG_ARM64 to the checked definitions alongside CONFIG_X86_64 to
enable the use of rbit/clz instructions on full 64-bit quantities.
Link:
On Fri, Nov 30, 2018 at 02:44:54PM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
>
> > On Fri, Nov 30, 2018 at 01:15:11PM +0100, Vitaly Kuznetsov wrote:
> >> Without 'packed' compiler is free to add optimization paddings and re-order
> >> structure fields for randomization/optimization.
In a function whose return type is void, returning on the last line is
not required.So remove it.Also move the module declaration to the end.
Signed-off-by: Yangtao Li
---
drivers/cpufreq/cpufreq-nforce2.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git
In a function whose return type is void, returning on the last line is
not required.So remove it.Also move the module declaration to the end.
Signed-off-by: Yangtao Li
---
drivers/cpufreq/cpufreq-nforce2.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git
Fix an extra space that sneaked in with commit 09c205afd "(x86, boot:
Define the 2.12 bzImage boot protocol").
Signed-off-by: Michael S. Tsirkin
---
Documentation/x86/boot.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/x86/boot.txt
Fix an extra space that sneaked in with commit 09c205afd "(x86, boot:
Define the 2.12 bzImage boot protocol").
Signed-off-by: Michael S. Tsirkin
---
Documentation/x86/boot.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/x86/boot.txt
On Fri, Nov 30, 2018 at 11:21:54AM +0100, Jiri Olsa wrote:
> On Fri, Nov 30, 2018 at 06:06:05PM +0800, Leo Yan wrote:
> > Since commit 0aa802a79469 ("perf stat: Get rid of extra clock display
> > function"), the cpu and task clock unit has been changed from
> > nanosecond value to millisecond
On Fri, Nov 30, 2018 at 11:21:54AM +0100, Jiri Olsa wrote:
> On Fri, Nov 30, 2018 at 06:06:05PM +0800, Leo Yan wrote:
> > Since commit 0aa802a79469 ("perf stat: Get rid of extra clock display
> > function"), the cpu and task clock unit has been changed from
> > nanosecond value to millisecond
801 - 900 of 1382 matches
Mail list logo
