Re: [PATCH v1] mm: relax deferred struct page requirements

On Thu 16-11-17 20:46:01, Pavel Tatashin wrote: > There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT, > as all the page initialization code is in common code. > > Also, there is no need to depend on MEMORY_HOTPLUG, as initialization code > does not really use hotplug memory

[PATCH 2/2] selftests/powerpc: Calculate spin time in tm-unavailable

Currently the tm-unavailable test spins for a fixed amount of time in an attempt to ensure the FPU/VMX/VSX facilities are off. This value was experimentally tested to be long enough. Problems may arise if kernel heuristics were to change. This patch should future proof this test. Signed-off-by:

[PATCH 1/2] selftests/powerpc: Check for pthread errors in tm-unavailable

Signed-off-by: Cyril Bur --- .../testing/selftests/powerpc/tm/tm-unavailable.c | 43 +- 1 file changed, 34 insertions(+), 9 deletions(-) diff --git a/tools/testing/selftests/powerpc/tm/tm-unavailable.c

Re: [PATCH v2] powerpc/powernv: Add pci_reset_phbs parameter to issue a PHB reset

On Thu, Nov 16, 2017 at 11:14 PM, Guilherme G. Piccoli wrote: > On 11/16/2017 01:49 AM, Balbir Singh wrote: >> On Thu, Oct 26, 2017 at 2:27 AM, Guilherme G. Piccoli >> wrote: >>> During a kdump kernel boot in PowerPC, we request a reset

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

On Sun, Nov 19, 2017 at 1:36 AM, LEROY Christophe wrote: > Meelis Roos a écrit : > >>> > > How early does it hang ? Any oops or trace ? >>> > >>> > Very early - instead oif kernel emssages, I see some repeated gibberish >>> > of some characteers, and the

Re: [alsa-devel] [PATCH 2/2] ASoC: fsl_ssi: serialize AC'97 register access operations

On Mon, Nov 20, 2017 at 11:16:07PM +0100, Maciej S. Szmigiero wrote: > AC'97 register access operations (both read and write) on SSI use a one, > shared set of SSI registers for AC'97 register address and data. > This means that only one such access is possible at a time and so all these >

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode

On Tue, Nov 21, 2017 at 01:32:09AM +0100, Maciej S. Szmigiero wrote: > On 21.11.2017 01:00, Nicolin Chen wrote: > > On Mon, Nov 20, 2017 at 11:13:45PM +0100, Maciej S. Szmigiero wrote: > (..) > >> We need to make sure, however, that only proper channel slots are enabled > >> at playback start time

Re: [alsa-devel] [PATCH 1/2] ASoC: fsl_ssi: AC'97 ops need regmap, clock and cleaning up on failure

On 21.11.2017 01:32, Nicolin Chen wrote: > On Mon, Nov 20, 2017 at 11:14:55PM +0100, Maciej S. Szmigiero wrote: (..) >> @@ -1460,12 +1460,6 @@ static int fsl_ssi_probe(struct platform_device *pdev) >> sizeof(fsl_ssi_ac97_dai)); >> >> fsl_ac97_data =

Re: [alsa-devel] [PATCH 1/2] ASoC: fsl_ssi: AC'97 ops need regmap, clock and cleaning up on failure

On Mon, Nov 20, 2017 at 11:14:55PM +0100, Maciej S. Szmigiero wrote: > AC'97 ops (register read / write) need SSI regmap and clock, so they have > to be set after them. > > We also need to set these ops back to NULL if we fail the probe. > > Signed-off-by: Maciej S. Szmigiero

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode

On 21.11.2017 01:00, Nicolin Chen wrote: > On Mon, Nov 20, 2017 at 11:13:45PM +0100, Maciej S. Szmigiero wrote: (..) >> We need to make sure, however, that only proper channel slots are enabled >> at playback start time since some AC'97 CODECs (like VT1613) were observed >> requesting via SLOTREQ

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode

On Mon, Nov 20, 2017 at 11:13:45PM +0100, Maciej S. Szmigiero wrote: > In AC'97 mode we configure and start SSI RX / TX on probe path via > a call to _fsl_ssi_set_dai_fmt() function. > We don't need to call this function again later and in fact don't want to > do it since this function temporarily

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: remove duplicated flag setting in fsl_ssi_setup_reg_vals()

On Mon, Nov 20, 2017 at 11:12:01PM +0100, Maciej S. Szmigiero wrote: > We don't need to set CCSR_SSI_SIER_RFF0_EN / CCSR_SSI_SIER_TFE0_EN bits > in reg->rx.sier / reg->tx.sier variables in a non-AC'97 mode considering we > had just initialized these variables to these very values unconditionally a

[PATCH] ASoC: fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode

In AC'97 mode we configure and start SSI RX / TX on probe path via a call to _fsl_ssi_set_dai_fmt() function. We don't need to call this function again later and in fact don't want to do it since this function temporarily sets STCR, SRCR and SCR to some intermediate values. We need to make sure,

[PATCH] ASoC: fsl_ssi: remove duplicated flag setting in fsl_ssi_setup_reg_vals()

We don't need to set CCSR_SSI_SIER_RFF0_EN / CCSR_SSI_SIER_TFE0_EN bits in reg->rx.sier / reg->tx.sier variables in a non-AC'97 mode considering we had just initialized these variables to these very values unconditionally a few lines earlier. Signed-off-by: Maciej S. Szmigiero

[PATCH 1/2] ASoC: fsl_ssi: AC'97 ops need regmap, clock and cleaning up on failure

AC'97 ops (register read / write) need SSI regmap and clock, so they have to be set after them. We also need to set these ops back to NULL if we fail the probe. Signed-off-by: Maciej S. Szmigiero --- sound/soc/fsl/fsl_ssi.c | 18 -- 1 file changed,

[PATCH 2/2] ASoC: fsl_ssi: serialize AC'97 register access operations

AC'97 register access operations (both read and write) on SSI use a one, shared set of SSI registers for AC'97 register address and data. This means that only one such access is possible at a time and so all these operations need to be serialized. Since an AC'97 register access operation in this

[PATCH] powerpc/vas, export chip_to_vas_id()

>From 958f8db089f4b89407fc4b89bccd3eaef585aa96 Mon Sep 17 00:00:00 2001 From: Sukadev Bhattiprolu Date: Mon, 20 Nov 2017 12:53:15 -0600 Subject: [PATCH 1/1] powerpc/vas, export chip_to_vas_id() Export the symbol chip_to_vas_id() to fix a build failure when

Re: [PATCH v3 10/18] powerpc/vas, nx-842: Define and use chip_to_vas_id()

On Tue, Nov 7, 2017 at 9:23 PM, Sukadev Bhattiprolu wrote: > Define a helper, chip_to_vas_id() to map a given chip id to corresponding > vas id. > > Normally, callers of vas_rx_win_open() and vas_tx_win_open() want the VAS > window to be on the same chip where the

Re: [PATCH V7 3/3] hotplug/cpu: Fix crash with memoryless nodes

On 11/16/2017 11:28 AM, Michael Bringmann wrote: > On powerpc systems with shared configurations of CPUs and memory and > memoryless nodes at boot, an event ordering problem was observed on > a SLES12 build platforms with the hot-add of CPUs to the memoryless > nodes. > > * The most common error

Re: RESEND [PATCH V7 2/3] poserpc/initnodes: Ensure nodes initialized for hotplug

On 11/16/2017 11:27 AM, Michael Bringmann wrote: > On powerpc systems which allow 'hot-add' of CPU, it may occur that > the new resources are to be inserted into nodes that were not used > for memory resources at bootup. Many different configurations of > PowerPC resources may need to be

Re: [PATCH V7 1/3] powerpc/nodes: Ensure enough nodes avail for operations

On 11/16/2017 11:24 AM, Michael Bringmann wrote: > On powerpc systems which allow 'hot-add' of CPU or memory resources, > it may occur that the new resources are to be inserted into nodes > that were not used for these resources at bootup. In the kernel, > any node that is used must be defined

Re: [PATCH V2 3/3] postmigration/memory: Associativity & ibm,dynamic-memory-v2

We may want to wait on this patch. I have been working on patches to separate the LMB information from the device tree property format. Once those patches are acceptable we can use a common routine for affinity updates. -Nathan On 11/16/2017 11:51 AM, Michael Bringmann wrote: >

Re: [PATCH V2 1/3] hotplug/mobility: Apply assoc updates for Post Migration Topo

On 11/16/2017 11:50 AM, Michael Bringmann wrote: > hotplug/mobility: Recognize more changes to the associativity of > memory blocks described by the 'ibm,dynamic-memory' and 'cpu' > properties when processing the topology of LPARS in Post Migration > events. Previous efforts only recognized

Re: Subject: [PATCH V4 3/4] hotplug/drc-info: Add code to search ibm,drc-info property

On 11/16/2017 02:11 PM, Michael Bringmann wrote: > rpadlpar_core.c: Provide parallel routines to search the older device- > tree properties ("ibm,drc-indexes", "ibm,drc-names", "ibm,drc-types" > and "ibm,drc-power-domains"), or the new property "ibm,drc-info". > > The interface to examine the DRC

Re: [PATCH V4 2/4] pseries/drc-info: Search DRC properties for CPU indexes

On 11/16/2017 02:11 PM, Michael Bringmann wrote: > pseries/drc-info: Provide parallel routines to convert between > drc_index and CPU numbers at runtime, using the older device-tree > properties ("ibm,drc-indexes", "ibm,drc-names", "ibm,drc-types" > and "ibm,drc-power-domains"), or the new

Re: [PATCH v2 0/8] powerpc: Support ibm,dynamic-memory-v2 property

On 11/16/2017 10:51 PM, Bharata B Rao wrote: > > On Thu, Nov 16, 2017 at 9:31 PM, Nathan Fontenot > wrote: > > > > On 11/15/2017 11:37 PM, Bharata B Rao wrote: > > On Fri, Oct 20, 2017 at 6:51 PM, Nathan Fontenot >