Re: [PATCH 4/6] powerpc/mm: Add devmap support for ppc64

On Tue, May 23, 2017 at 8:40 PM, Balbir Singh wrote: > On Tue, May 23, 2017 at 2:05 PM, Oliver O'Halloran wrote: >> Add support for the devmap bit on PTEs and PMDs for PPC64 Book3S. This >> is used to differentiate device backed memory from transparent

Re: SPU not working for kernel 4.9, 4.10, 4.11a and 4.12

Jeremy Kerr writes: > Hi all, > > >> Looks like this also happens with the simple spu_run test: >> >> >> https://github.com/jk-ozlabs/spufs-testsuite/blob/master/tests/03-spu_run/01-spu_run.c >> >> ... might need some debugging here, I'll update if I find anything. > > And

[PATCH] powerpc/lib: Split xor_vmx file to guarantee instruction ordering

The xor_vmx.c file is used for the RAID5 xor operations. In these functions altivec is enabled to run the operation and then disabled. However due to compiler instruction reordering, altivec instructions are being run before enable_altivec() and after disable_altivec(). This patch splits the

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

On 05/23/2017 04:49 PM, Reza Arbab wrote: > On Tue, May 23, 2017 at 03:05:08PM -0500, Michael Bringmann wrote: >> On 05/23/2017 10:52 AM, Reza Arbab wrote: >>> On Tue, May 23, 2017 at 10:15:44AM -0500, Michael Bringmann wrote: +static void setup_nodes(void) +{ +int i, l = 32

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

On 05/23/2017 04:49 PM, Reza Arbab wrote: > On Tue, May 23, 2017 at 03:05:08PM -0500, Michael Bringmann wrote: >> On 05/23/2017 10:52 AM, Reza Arbab wrote: >>> On Tue, May 23, 2017 at 10:15:44AM -0500, Michael Bringmann wrote: +static void setup_nodes(void) +{ +int i, l = 32

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

On Tue, May 23, 2017 at 03:05:08PM -0500, Michael Bringmann wrote: On 05/23/2017 10:52 AM, Reza Arbab wrote: On Tue, May 23, 2017 at 10:15:44AM -0500, Michael Bringmann wrote: +static void setup_nodes(void) +{ +int i, l = 32 /* MAX_NUMNODES */; + +for (i = 0; i < l; i++) { +if

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

On 05/23/2017 10:52 AM, Reza Arbab wrote: > On Tue, May 23, 2017 at 10:15:44AM -0500, Michael Bringmann wrote: >> +static void setup_nodes(void) >> +{ >> +int i, l = 32 /* MAX_NUMNODES */; >> + >> +for (i = 0; i < l; i++) { >> +if (!node_possible(i)) { >> +

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

On Tue, May 23, 2017 at 10:15:44AM -0500, Michael Bringmann wrote: +static void setup_nodes(void) +{ + int i, l = 32 /* MAX_NUMNODES */; + + for (i = 0; i < l; i++) { + if (!node_possible(i)) { + setup_node_data(i, 0, 0); +

[Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

Removing or adding memory via the PowerPC hotplug interface shows anomalies in the association between memory and nodes. The code was updated to initialize more possible nodes to make them available to subsequent DLPAR hotplug-memory operations, even if they are not needed at boot time.

[PATCH 1/2] powerpc/numa: Update CPU topology when VPHN enabled

powerpc/numa: Correct the currently broken capability to set the topology for shared CPUs in LPARs. At boot time for shared CPU lpars, the topology for each shared CPU is set to node zero, however, this is now updated correctly using the Virtual Processor Home Node (VPHN) capabilities

[PATCH 0/2] powerpc/dlpar: Correct display of hot-add/hot-remove CPUs and memory

powerpc/numa: Correct the currently broken capability to set the topology for shared CPUs in LPARs. At boot time for shared CPU lpars, the topology for each shared CPU is set to node zero, however, this is now updated correctly using the Virtual Processor Home Node (VPHN) capabilities

Re: [PATCH v4 19/20] powerpc/83xx: Add generic compatible string for I2C EEPROM

Hello Rob, On Tue, May 23, 2017 at 3:42 PM, Rob Herring wrote: > On Mon, May 22, 2017 at 9:02 AM, Javier Martinez Canillas > wrote: >> The at24 driver allows to register I2C EEPROM chips using different vendor >> and devices, but the I2C subsystem does not

Re: [PATCH v4 19/20] powerpc/83xx: Add generic compatible string for I2C EEPROM

On Mon, May 22, 2017 at 9:02 AM, Javier Martinez Canillas wrote: > The at24 driver allows to register I2C EEPROM chips using different vendor > and devices, but the I2C subsystem does not take the vendor into account > when matching using the I2C table since it only has

[PATCH v5 20/20] powerpc/44x: Add generic compatible string for I2C EEPROM

The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken

[PATCH v5 19/20] powerpc/83xx: Add generic compatible string for I2C EEPROM

The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken

[PATCH v5 18/20] powerpc/512x: Add generic compatible string for I2C EEPROM

The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken

[PATCH v5 17/20] powerpc/fsl: Add generic compatible string for I2C EEPROM

The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken

[PATCH v5 16/20] powerpc/5200: Add generic compatible string for I2C EEPROM

The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken

[PATCH v5 00/20] eeprom: at24: Add OF device ID table

Hello Wolfram, This series is a follow-up to patch [0] that added an OF device ID table to the at24 EEPROM driver. As you suggested [1], this version instead of adding entries for every used tuple, only adds a single entry for each chip type using the "atmel" vendor as a generic

RE: RFC: better timer interface

On Tue, 23 May 2017, David Laight wrote: > From: Thomas Gleixner > > Sent: 23 May 2017 12:59 > > On Tue, 23 May 2017, David Laight wrote: > > > > > From: Thomas Gleixner > > > > Sent: 21 May 2017 19:15 > > > ... > > > > > timer_start(timer, ms, abs) > > > > > > > > I'm not even sure, whether we

RE: RFC: better timer interface

From: Thomas Gleixner > Sent: 23 May 2017 12:59 > On Tue, 23 May 2017, David Laight wrote: > > > From: Thomas Gleixner > > > Sent: 21 May 2017 19:15 > > ... > > > > timer_start(timer, ms, abs) > > > > > > I'm not even sure, whether we need absolute timer wheel timers at > > > all, because most

RE: RFC: better timer interface

On Tue, 23 May 2017, David Laight wrote: > From: Thomas Gleixner > > Sent: 21 May 2017 19:15 > ... > > > timer_start(timer, ms, abs) > > > > I'm not even sure, whether we need absolute timer wheel timers at > > all, because most use cases are relative to now. > > Posix requires absolute timers

RE: RFC: better timer interface

From: Thomas Gleixner > Sent: 21 May 2017 19:15 ... > > timer_start(timer, ms, abs) > > I'm not even sure, whether we need absolute timer wheel timers at > all, because most use cases are relative to now. Posix requires absolute timers for some userspace calls (annoying because the code often

Re: [PATCH 4/6] powerpc/mm: Add devmap support for ppc64

On Tue, May 23, 2017 at 2:05 PM, Oliver O'Halloran wrote: > Add support for the devmap bit on PTEs and PMDs for PPC64 Book3S. This > is used to differentiate device backed memory from transparent huge > pages since they are handled in more or less the same manner by the core >

Re: [PATCH 1/6] powerpc/mm: Wire up hpte_removebolted for powernv

On Tue, May 23, 2017 at 2:05 PM, Oliver O'Halloran wrote: > From: Anton Blanchard > > Adds support for removing bolted (i.e kernel linear mapping) mappings on > powernv. This is needed to support memory hot unplug operations which > are required for the

Re: [PATCH 3/6] powerpc/vmemmap: Add altmap support

On Tue, May 23, 2017 at 2:05 PM, Oliver O'Halloran wrote: > Adds support to powerpc for the altmap feature of ZONE_DEVICE memory. An > altmap is a driver provided region that is used to provide the backing > storage for the struct pages of ZONE_DEVICE memory. In situations where

Re: [PATCH 6/6] powerpc/mm: Enable ZONE_DEVICE on powerpc

On Tue, May 23, 2017 at 2:05 PM, Oliver O'Halloran wrote: > Flip the switch. Running around and screaming "IT'S ALIVE" is optional, > but recommended. > > Signed-off-by: Oliver O'Halloran > --- > arch/powerpc/Kconfig | 1 + > 1 file changed, 1 insertion(+) >

Re: [PATCH 5/6] mm, x86: Add ARCH_HAS_ZONE_DEVICE

On Tue, May 23, 2017 at 2:05 PM, Oliver O'Halloran wrote: > Currently ZONE_DEVICE depends on X86_64. This is fine for now, but it > will get unwieldly as new platforms get ZONE_DEVICE support. Moving it > to an arch selected Kconfig option to save us some trouble in the >

Re: SPU not working for kernel 4.9, 4.10, 4.11a and 4.12

Hi all, > Looks like this also happens with the simple spu_run test: > > > https://github.com/jk-ozlabs/spufs-testsuite/blob/master/tests/03-spu_run/01-spu_run.c > > ... might need some debugging here, I'll update if I find anything. And it appears we're stuck in the POLL_WHILE_FALSE() loop

[PATCH] powerpc/fadump: add reschedule point while releasing memory

Around 95% of memory is reserved by fadump/capture kernel. All this memory is freed, one page at a time, on writing '1' to the node /sys/kernel/fadump_release_mem. On systems with large memory, this can take a long time to complete, leading to soft lockup warning messages. To avoid this, add

Re: [PATCH 4/6] powerpc/mm: Add devmap support for ppc64

On Tue, May 23, 2017 at 2:23 PM, Aneesh Kumar K.V wrote: > Oliver O'Halloran writes: > >> Add support for the devmap bit on PTEs and PMDs for PPC64 Book3S. This >> is used to differentiate device backed memory from transparent huge >> pages

Re: [PATCH 5/6] mm, x86: Add ARCH_HAS_ZONE_DEVICE

* Oliver O'Halloran wrote: > Currently ZONE_DEVICE depends on X86_64. This is fine for now, but it > will get unwieldly as new platforms get ZONE_DEVICE support. Moving it > to an arch selected Kconfig option to save us some trouble in the > future. > > Cc: x...@kernel.org >

Re: [PowerPC][next-20170324][kselftest] kernel Oops when running tm/tm-signal-context-chk-vsx

On Mon, 2017-04-03 at 14:33 +0530, Abdul Haleem wrote: > On Mon, 2017-04-03 at 14:28 +0530, Abdul Haleem wrote: > > On Tue, 2017-03-28 at 21:00 +1100, Michael Ellerman wrote: > > > Abdul Haleem writes: > > > > > > > Hi, > > > > > > > > While running kernel self tests