Re: [PATCH v3 2/3] devcietree: bindings: add some MFD Keymile FPGAs
On 04/09/2014 02:44 AM, Scott Wood wrote:
On Tue, 2014-03-25 at 14:41 +0100, Valentin Longchamp wrote:
These are the bindings for 2 MFD devices used on some of the Keymile boards.
The first one is the chassis managmenet bfticu FPGA.
The second one is the board controller (reset, LEDs, GPIOs) QRIO CPDL.
These FPGAs are used in the kmcoge4 board.
This patch also add KEYMILE to the vendor-prefixes.
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
Changes in v3:
- add a patch with the bindings for the KEYMILE FPGAs
Changes in v2: None
Documentation/devicetree/bindings/mfd/bfticu.txt | 26
++
Documentation/devicetree/bindings/mfd/qriox.txt| 17 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
3 files changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt
create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt
diff --git a/Documentation/devicetree/bindings/mfd/bfticu.txt
b/Documentation/devicetree/bindings/mfd/bfticu.txt
new file mode 100644
index 000..92de32e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/bfticu.txt
@@ -0,0 +1,26 @@
+KEYMILE bfticu Chassis Management FPGA
+
+The bfticu is a multifunction device that manages the whole chassis.
+Its main functionality is to collect IRQs from the whole chassis and signals
+them to a single controller.
+
+Required properties:
+- compatible: keymile,bfticu
+- interrupt-controller: the bfticu FPGA is an interrupt controller
+- interrupts: the main IRQ line to signal the collected IRQs
+- #interrupt-cells : is 2
+- The 1st cell is the local IRQ number on the bfticu
+- The 2nd cell is the type of the IRQ (IRQ_TYPE_xxx)
Device tree bindings should not depend on the content of Linux headers.
One is stable ABI, and the other isn't.
If you want you can make the values the same for convenience, as is done
by IPIC, CPM PIC, etc -- but the values need to be explicitly stated in
the binding. It'll still break if the Linux values change (so it may
not be a good idea to try to keep the values the same), but at least the
fix would be in Linux code rather than an ABI change.
OK. I will then explicitly give the list of the values.
diff --git a/Documentation/devicetree/bindings/mfd/qriox.txt
b/Documentation/devicetree/bindings/mfd/qriox.txt
new file mode 100644
index 000..f301e2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qriox.txt
@@ -0,0 +1,17 @@
+KEYMILE qrio Board Control CPLD
+
+The qrio is a multifunction device that controls the KEYMILE boards based on
+the kmp204x design.
+It is consists of a reset controller, watchdog timer, LEDs, and 2 IRQ
capable
+GPIO blocks.
+
+Required properties:
+- compatible: keymile,qriox
+- reg: access on the parent local bus (chip select, offset in chip select,
size)
+
+Example:
+
+board-control@1,0 {
+compatible = keymile,qriox;
+reg = 1 0 0x80;
+};
If it has GPIO blocks, shouldn't it be using the GPIO binding?
You are right it should. But this is currently being reworked (also in HW) and
that's why I left it out completely, instead of submitting something subject to
change.
Valentin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are a few more powerpc things for you. So you'll find here the conversion of the two new firmware sysfs interfaces to the new API for self-removing files that Greg and Tejun introduced, so they can finally remove the old one. I'm also reverting the hwmon driver for powernv. I shouldn't have merged it, I got a bit carried away here. I hadn't realized it was never CCed to the relevant maintainer(s) and list(s), and happens to have some issues so I'm taking it out and it will come back via the proper channels. The rest is a bunch of LE fixes (argh, some of the new stuff was broken on LE, I really need to start testing LE myself !) and various random fixes here and there. Finally one bit that's not strictly a fix, which is the HVC OPAL change to kick the HVC thread when the firmware tells us there is new incoming data. I don't feel like waiting for this one, it's simple enough, and it makes a big difference in console responsiveness which is good for my nerves. Cheers, Ben. The following changes since commit 18a1a7a1d862ae0794a0179473d08a414dd49234: Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile (2014-04-06 08:11:57 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to cc4f265ad9a37bdb1846c45eebe454c382f31d67: powerpc/powernv Adapt opal-elog and opal-dump to new sysfs_remove_file_self (2014-04-09 13:51:50 +1000) Aneesh Kumar K.V (1): powerpc/mm: NUMA pte should be handled via slow path in get_user_pages_fast() Anton Blanchard (3): powerpc/powernv: Fix endian issues with OPAL async code powerpc/powernv: Fix endian issues with sensor code powerpc: Add lq/stq emulation Benjamin Herrenschmidt (8): powerpc: Adjust CPU_FTR_SMT on all platforms powerpc: Make boot_cpuid common between 32 and 64-bit powerpc/prom: early_init_dt_scan_cpus() updates cpu features only once powerpc/ppc64: Gracefully handle early interrupts powerpc/ppc64: Do not turn AIL (reloc-on interrupts) too early powerpc/powernv: Add opal_notifier_unregister() and export to modules tty/hvc_opal: Kick the HVC thread on OPAL console events Revert powerpc/powernv: hwmon driver for power values, fan rpm and temperature Greg Kurz (1): powerpc/le: Enable RTAS events support Joe Perches (1): powerpc: Convert last uses of __FUNCTION__ to __func__ Joel Stanley (2): powerpc/powernv: Add OPAL message log interface powerpc/powernv: Add invalid OPAL call Li Zhong (1): powerpc: Use of_node_init() for the fakenode in msi_bitmap.c Mahesh Salgaonkar (1): powerpc/book3s: Fix mc_recoverable_range buffer overrun issue. Michael Neuling (3): powerpc/tm: Disable IRQ in tm_recheckpoint powerpc: Remove dead code in sycall entry powerpc/opal: Add missing include Michael Wang (1): power, sched: stop updating inside arch_update_cpu_topology() when nothing to be update Monam Agarwal (1): arch/powerpc: Use RCU_INIT_POINTER(x, NULL) in platforms/cell/spu_syscalls.c Stephen Chivers (1): powerpc: Correct emulated mtfsf instruction Stewart Smith (1): powerpc/powernv Adapt opal-elog and opal-dump to new sysfs_remove_file_self Tony Breeds (1): powerpc/le: Avoid creatng R_PPC64_TOCSAVE relocations for modules. arch/powerpc/Makefile | 1 + arch/powerpc/include/asm/emulated_ops.h| 1 + arch/powerpc/include/asm/opal.h| 19 +- arch/powerpc/include/asm/rtas.h| 127 -- arch/powerpc/kernel/align.c| 52 ++- arch/powerpc/kernel/cpu_setup_power.S | 2 - arch/powerpc/kernel/exceptions-64s.S | 8 - arch/powerpc/kernel/paca.c | 3 +- arch/powerpc/kernel/process.c | 34 +- arch/powerpc/kernel/prom.c | 58 +-- arch/powerpc/kernel/rtas.c | 15 +- arch/powerpc/kernel/rtasd.c| 24 +- arch/powerpc/kernel/setup-common.c | 3 + arch/powerpc/kernel/setup_32.c | 2 - arch/powerpc/kernel/setup_64.c | 28 +- arch/powerpc/kernel/signal_32.c| 2 + arch/powerpc/kernel/signal_64.c| 2 + arch/powerpc/kernel/tm.S | 2 +- arch/powerpc/kernel/traps.c| 1 + arch/powerpc/math-emu/mtfsf.c | 58 ++- arch/powerpc/mm/gup.c | 13 + arch/powerpc/mm/numa.c | 15 + arch/powerpc/platforms/cell/spu_syscalls.c | 2 +- arch/powerpc/platforms/powernv/Makefile| 1 + arch/powerpc/platforms/powernv/opal-async.c| 7 +- arch/powerpc/platforms/powernv/opal-dump.c | 9 +-
Re: [PATCH v3 2/2] ARM: dts: Append clock bindings for sai2 on VF610 platform
On Fri, Apr 04, 2014 at 06:08:13PM +0800, Nicolin Chen wrote: Since we added fours clock to the DT binding, we should update the current SAI dts/dtsi so as not to break their functions. If so, shouldn't the change be in the same patch as driver change? Shawn Signed-off-by: Nicolin Chen guangyu.c...@freescale.com Tested-by: Xiubo Li li.xi...@freescale.com --- arch/arm/boot/dts/vf610.dtsi | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi index d31ce1b..9fd0007 100644 --- a/arch/arm/boot/dts/vf610.dtsi +++ b/arch/arm/boot/dts/vf610.dtsi @@ -139,8 +139,10 @@ compatible = fsl,vf610-sai; reg = 0x40031000 0x1000; interrupts = 0 86 0x04; - clocks = clks VF610_CLK_SAI2; - clock-names = sai; + clocks = clks VF610_CLK_SAI2, +clks VF610_CLK_SAI2, +clks 0, clks 0; + clock-names = bus, mclk1, mclk2, mclk3; status = disabled; }; -- 1.8.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] ARM: dts: Append clock bindings for sai2 on VF610 platform
On Wed, Apr 09, 2014 at 03:58:15PM +0800, Shawn Guo wrote: On Fri, Apr 04, 2014 at 06:08:13PM +0800, Nicolin Chen wrote: Since we added fours clock to the DT binding, we should update the current SAI dts/dtsi so as not to break their functions. If so, shouldn't the change be in the same patch as driver change? Okay..I'd like to merge them into one patch. Thank you, Nicolin Shawn Signed-off-by: Nicolin Chen guangyu.c...@freescale.com Tested-by: Xiubo Li li.xi...@freescale.com --- arch/arm/boot/dts/vf610.dtsi | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi index d31ce1b..9fd0007 100644 --- a/arch/arm/boot/dts/vf610.dtsi +++ b/arch/arm/boot/dts/vf610.dtsi @@ -139,8 +139,10 @@ compatible = fsl,vf610-sai; reg = 0x40031000 0x1000; interrupts = 0 86 0x04; - clocks = clks VF610_CLK_SAI2; - clock-names = sai; + clocks = clks VF610_CLK_SAI2, + clks VF610_CLK_SAI2, + clks 0, clks 0; + clock-names = bus, mclk1, mclk2, mclk3; status = disabled; }; -- 1.8.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] ARM: dts: Append clock bindings for sai2 on VF610 platform
On Fri, Apr 04, 2014 at 06:08:13PM +0800, Nicolin Chen wrote: Since we added fours clock to the DT binding, we should update the current SAI dts/dtsi so as not to break their functions. For the record, you're asking my ACK to have the dts change go via sound tree for not breaking vf610 function on the sound branch, while ignoring the fact that the existing DTB will break with the new kernel anyway. I'm not completely happy with the approach, but considering that the existing binding is incorrect, I'm fine with it as long as people agree to go this way. Shawn Signed-off-by: Nicolin Chen guangyu.c...@freescale.com Tested-by: Xiubo Li li.xi...@freescale.com --- arch/arm/boot/dts/vf610.dtsi | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi index d31ce1b..9fd0007 100644 --- a/arch/arm/boot/dts/vf610.dtsi +++ b/arch/arm/boot/dts/vf610.dtsi @@ -139,8 +139,10 @@ compatible = fsl,vf610-sai; reg = 0x40031000 0x1000; interrupts = 0 86 0x04; - clocks = clks VF610_CLK_SAI2; - clock-names = sai; + clocks = clks VF610_CLK_SAI2, +clks VF610_CLK_SAI2, +clks 0, clks 0; + clock-names = bus, mclk1, mclk2, mclk3; status = disabled; }; -- 1.8.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 1/2] mm: move FAULT_AROUND_ORDER to arch/
On Wed, Apr 09, 2014 at 07:02:02AM +0530, Madhavan Srinivasan wrote: On Friday 04 April 2014 09:48 PM, Dave Hansen wrote: On 04/03/2014 11:27 PM, Madhavan Srinivasan wrote: This patch creates infrastructure to move the FAULT_AROUND_ORDER to arch/ using Kconfig. This will enable architecture maintainers to decide on suitable FAULT_AROUND_ORDER value based on performance data for that architecture. Patch also adds FAULT_AROUND_ORDER Kconfig element in arch/X86. Please don't do it this way. In mm/Kconfig, put config FAULT_AROUND_ORDER int default 1234 if POWERPC default 4 The way you have it now, every single architecture that needs to enable this has to go put that in their Kconfig. That's madness. This way, I though about it and decided not to do this way because, in future, sub platforms of the architecture may decide to change the values. Also, adding an if line for each architecture with different sub platforms oring to it will look messy. This still misses out on Ben's objection that its impossible to get this right at compile time for many kernels, since they can boot and run on many different subarchs. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC PATCH powerpc] Protect remove_memory() with device hotplug lock
While testing memory hot-remove, I found following dead lock:
Process #1141 is drmgr, trying to remove some memory, i.e. memory499.
It holds the memory_hotplug_mutex, and blocks when trying to remove file
online under dir memory499, in kernfs_drain(), at
wait_event(root-deactivate_waitq,
atomic_read(kn-active) == KN_DEACTIVATED_BIAS);
Process #1120 is trying to online memory499 by
echo 1 memory499/online
In .kernfs_fop_write, it uses kernfs_get_active() to increase
kn-active, thus blocking process #1141. While itself is blocked later
when trying to acquire memory_hotplug_mutex, which is held by process
#1141.
The backtrace of both processes are shown below:
# cat /proc/1120/stack
[c1b18600] 0xc1b18600
[c0015044] .__switch_to+0x144/0x200
[c0263ca4] .online_pages+0x74/0x7b0
[c055b40c] .memory_subsys_online+0x9c/0x150
[c053cbe8] .device_online+0xb8/0x120
[c053cd04] .online_store+0xb4/0xc0
[c0538ce4] .dev_attr_store+0x64/0xa0
[c030f4ec] .sysfs_kf_write+0x7c/0xb0
[c030e574] .kernfs_fop_write+0x154/0x1e0
[c0268450] .vfs_write+0xe0/0x260
[c0269144] .SyS_write+0x64/0x110
[c0009ffc] syscall_exit+0x0/0x7c
# cat /proc/1141/stack
[c1b18600] 0xc1b18600
[c0015044] .__switch_to+0x144/0x200
[c030be14] .__kernfs_remove+0x204/0x300
[c030d428] .kernfs_remove_by_name_ns+0x68/0xf0
[c030fb38] .sysfs_remove_file_ns+0x38/0x60
[c0539354] .device_remove_attrs+0x54/0xc0
[c0539fd8] .device_del+0x158/0x250
[c053a104] .device_unregister+0x34/0xa0
[c055bc14] .unregister_memory_section+0x164/0x170
[c024ee18] .__remove_pages+0x108/0x4c0
[c004b590] .arch_remove_memory+0x60/0xc0
[c026446c] .remove_memory+0x8c/0xe0
[c007f9f4] .pseries_remove_memblock+0xd4/0x160
[c007fcfc] .pseries_memory_notifier+0x27c/0x290
[c08ae6cc] .notifier_call_chain+0x8c/0x100
[c00d858c] .__blocking_notifier_call_chain+0x6c/0xe0
[c071ddec] .of_property_notify+0x7c/0xc0
[c071ed3c] .of_update_property+0x3c/0x1b0
[c00756cc] .ofdt_write+0x3dc/0x740
[c02f60fc] .proc_reg_write+0xac/0x110
[c0268450] .vfs_write+0xe0/0x260
[c0269144] .SyS_write+0x64/0x110
[c0009ffc] syscall_exit+0x0/0x7c
This patch uses lock_device_hotplug() to protect remove_memory() called
in pseries_remove_memblock(), which is also stated before function
remove_memory():
* NOTE: The caller must call lock_device_hotplug() to serialize hotplug
* and online/offline operations before this call, as required by
* try_offline_node().
*/
void __ref remove_memory(int nid, u64 start, u64 size)
With this lock held, the other process(#1120 above) trying to online the
memory block will retry the system call when calling
lock_device_hotplug_sysfs(), and finally find No such device error.
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 573b488..e96357c 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -109,10 +109,12 @@ static int pseries_remove_memblock(unsigned long base,
unsigned int memblock_siz
sections_per_block = block_sz / MIN_MEMORY_BLOCK_SIZE;
nid = memory_add_physaddr_to_nid(base);
+ lock_device_hotplug();
for (i = 0; i sections_per_block; i++) {
remove_memory(nid, base, MIN_MEMORY_BLOCK_SIZE);
base += MIN_MEMORY_BLOCK_SIZE;
}
+ unlock_device_hotplug();
/* Update memory regions for memory remove */
memblock_remove(base, memblock_size);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] ARM: dts: Append clock bindings for sai2 on VF610 platform
Hi Shawn, On Wed, Apr 09, 2014 at 04:11:38PM +0800, Shawn Guo wrote: On Fri, Apr 04, 2014 at 06:08:13PM +0800, Nicolin Chen wrote: Since we added fours clock to the DT binding, we should update the current SAI dts/dtsi so as not to break their functions. For the record, you're asking my ACK to have the dts change go via sound tree for not breaking vf610 function on the sound branch, while ignoring the fact that the existing DTB will break with the new kernel anyway. I'm not completely happy with the approach, but considering that the existing binding is incorrect, I'm fine with it as long as people agree to go this way. Although I'm not a big fan of explaining, yet, I still want to say that actually I've balanced this way and your last suggestion against the v1. It'd be surely better to distinguish two platforms as you suggested if we are looking at this change alone since the change is nearly tiny and the code to specify them wouldn't be quite a lot. However, there's more work to do based on this patch, an auto-selecting clock source mechanism for SAI as a DAI master for example, which would need to drop the existing code and to add the new one. If vf610 is still using the old one, it would not benefit from the further feature and the code would be definitely ugly as we would have to add too many platform checks. So personally I prefer this reasonable change than the little sacrifice we're going to make here. Right now I feel grateful for what Sascha suggested to the DT bindings of fsl-spdif. It was a painstaking experience when getting it upstream last year but what's done at that moment makes the driver more flexible. So I think we should do the strict and comprehensive review for the clock part to every module from now on since an once-defined-DT-binding would be so painful to improved for us. Thank you, Nicolin Shawn Signed-off-by: Nicolin Chen guangyu.c...@freescale.com Tested-by: Xiubo Li li.xi...@freescale.com --- arch/arm/boot/dts/vf610.dtsi | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi index d31ce1b..9fd0007 100644 --- a/arch/arm/boot/dts/vf610.dtsi +++ b/arch/arm/boot/dts/vf610.dtsi @@ -139,8 +139,10 @@ compatible = fsl,vf610-sai; reg = 0x40031000 0x1000; interrupts = 0 86 0x04; - clocks = clks VF610_CLK_SAI2; - clock-names = sai; + clocks = clks VF610_CLK_SAI2, + clks VF610_CLK_SAI2, + clks 0, clks 0; + clock-names = bus, mclk1, mclk2, mclk3; status = disabled; }; -- 1.8.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/powernv Adapt opal-elog and opal-dump to new sysfs_remove_file_self API from (removed) sysfs_schedule_callback
A merge fix for powernv opal-dump and opal-elog code with driver-next
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/opal-dump.c |9 ++---
arch/powerpc/platforms/powernv/opal-elog.c |9 ++---
2 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-dump.c
b/arch/powerpc/platforms/powernv/opal-dump.c
index 0c767c5..b9827b0 100644
--- a/arch/powerpc/platforms/powernv/opal-dump.c
+++ b/arch/powerpc/platforms/powernv/opal-dump.c
@@ -86,19 +86,14 @@ static int64_t dump_send_ack(uint32_t dump_id)
return rc;
}
-static void delay_release_kobj(void *kobj)
-{
- kobject_put((struct kobject *)kobj);
-}
-
static ssize_t dump_ack_store(struct dump_obj *dump_obj,
struct dump_attribute *attr,
const char *buf,
size_t count)
{
dump_send_ack(dump_obj-id);
- sysfs_schedule_callback(dump_obj-kobj, delay_release_kobj,
- dump_obj-kobj, THIS_MODULE);
+ sysfs_remove_file_self(dump_obj-kobj, attr-attr);
+ kobject_put(dump_obj-kobj);
return count;
}
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c
b/arch/powerpc/platforms/powernv/opal-elog.c
index 1d7355b..ef7bc2a 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -70,19 +70,14 @@ static ssize_t elog_ack_show(struct elog_obj *elog_obj,
return sprintf(buf, ack - acknowledge log message\n);
}
-static void delay_release_kobj(void *kobj)
-{
- kobject_put((struct kobject *)kobj);
-}
-
static ssize_t elog_ack_store(struct elog_obj *elog_obj,
struct elog_attribute *attr,
const char *buf,
size_t count)
{
opal_send_ack_elog(elog_obj-id);
- sysfs_schedule_callback(elog_obj-kobj, delay_release_kobj,
- elog_obj-kobj, THIS_MODULE);
+ sysfs_remove_file_self(elog_obj-kobj, attr-attr);
+ kobject_put(elog_obj-kobj);
return count;
}
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/rmu: Fix the error memory free parameters
There are error parameters should be corrected when
calling dma_free_coherent to free rmu rx-ring buffers
in fsl_open_inb_mbox() function.
Signed-off-by: Liu Gang gang@freescale.com
Reported-by: Dan Carpenter dan.carpen...@oracle.com
---
arch/powerpc/sysdev/fsl_rmu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
index 00e224a..b48197a 100644
--- a/arch/powerpc/sysdev/fsl_rmu.c
+++ b/arch/powerpc/sysdev/fsl_rmu.c
@@ -881,9 +881,9 @@ fsl_open_inb_mbox(struct rio_mport *mport, void *dev_id,
int mbox, int entries)
rc = request_irq(IRQ_RIO_RX(mport), fsl_rio_rx_handler, 0,
msg_rx, (void *)mport);
if (rc 0) {
- dma_free_coherent(priv-dev, RIO_MSG_BUFFER_SIZE,
- rmu-msg_tx_ring.virt_buffer[i],
- rmu-msg_tx_ring.phys_buffer[i]);
+ dma_free_coherent(priv-dev,
+ rmu-msg_rx_ring.size * RIO_MAX_MSG_SIZE,
+ rmu-msg_rx_ring.virt, rmu-msg_rx_ring.phys);
goto out;
}
--
1.8.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: hugetlb: ensure hugepage access is denied if hugepages are not supported
On Thu, Apr 03, 2014 at 04:14:13PM -0700, Nishanth Aravamudan wrote:
In KVM guests on Power, in a guest not backed by hugepages, we see the
following:
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize: 64 kB
HPAGE_SHIFT == 0 in this configuration, which indicates that hugepages
are not supported at boot-time, but this is only checked in
hugetlb_init(). Extract the check to a helper function, and use it in a
few relevant places.
This does make hugetlbfs not supported (not registered at all) in this
environment. I believe this is fine, as there are no valid hugepages and
that won't change at runtime.
Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
Acked-by: Mel Gorman mgor...@suse.de
This patch looks ok but the changelog misses important information from
the original report which is probably why it fell through the cracks.
Add the fact that you encountered a problem during mount to the changelog
and resend it directly to Andrew. This part from your original report;
Currently, I am seeing the following when I `mount -t hugetlbfs
/none /dev/hugetlbfs`, and then simply do a `ls /dev/hugetlbfs`. I
think it's related to the fact that hugetlbfs is properly not
correctly setting itself up in this state?:
Unable to handle kernel paging request for data at address 0x0031
Faulting instruction address: 0xc0245710
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 NUMA pSeries
It probably slipped through the cracks because from the changelog this
looks like a minor formatting issue and not a functional fix.
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index d19b30a..cc8fcc7 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -1017,6 +1017,11 @@ static int __init init_hugetlbfs_fs(void)
int error;
int i;
+ if (!hugepages_supported()) {
+ printk(KERN_ERR hugetlbfs: Disabling because there are no
supported hugepage sizes\n);
+ return -ENOTSUPP;
+ }
+
error = bdi_init(hugetlbfs_backing_dev_info);
if (error)
return error;
KERN_ERR feels like overkill for this type of issue. KERN_INFO?
--
Mel Gorman
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4] ASoC: fsl_sai: Add clock controls for SAI
The SAI mainly has the following clocks:
bus clock
control and configure registers and to generate synchronous
interrupts and DMA requests.
mclk1, mclk2, mclk3
to generate the bit clock when the receiver or transmitter is
configured for an internally generated bit clock.
So this patch adds these clocks and their clock controls to the driver,
meanwhile, corrects the existing DTS accordingly so those platforms can
benifit from the further feature with different clock sources.
Signed-off-by: Nicolin Chen guangyu.c...@freescale.com
CC: Xiubo Li li.xi...@freescale.com
Acked-by: Shawn Guo shawn@linaro.org
---
@Xiubo
Even though you've tested it before, I'd still like to wait for your test
result to this newer version.
Changelog
v4:
* Merged into single patch.
* Fixed bus clock ID on vf610.
v3:
* Use int type for ret instead of u32.
* Added Acked-by and Tested-by from Xiubo Li.
v2:
* Appended two extra mclks to the driver since SAI actually has three.
* Renamed clock name to 'bus' and 'mclk' according to the reference manual.
.../devicetree/bindings/sound/fsl-sai.txt | 9 ++--
arch/arm/boot/dts/vf610.dtsi | 6 ++-
sound/soc/fsl/fsl_sai.c| 51 --
sound/soc/fsl/fsl_sai.h| 4 ++
4 files changed, 61 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt
b/Documentation/devicetree/bindings/sound/fsl-sai.txt
index 35c09fe..0f4e238 100644
--- a/Documentation/devicetree/bindings/sound/fsl-sai.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt
@@ -10,7 +10,8 @@ Required properties:
- compatible: Compatible list, contains fsl,vf610-sai or fsl,imx6sx-sai.
- reg: Offset and length of the register set for the device.
- clocks: Must contain an entry for each entry in clock-names.
-- clock-names : Must include the sai entry.
+- clock-names : Must include the bus for register access and mclk1 mclk2
+ mclk3 for bit clock and frame clock providing.
- dmas : Generic dma devicetree binding as described in
Documentation/devicetree/bindings/dma/dma.txt.
- dma-names : Two dmas have to be defined, tx and rx.
@@ -30,8 +31,10 @@ sai2: sai@40031000 {
reg = 0x40031000 0x1000;
pinctrl-names = default;
pinctrl-0 = pinctrl_sai2_1;
- clocks = clks VF610_CLK_SAI2;
- clock-names = sai;
+ clocks = clks VF610_CLK_PLATFORM_BUS,
+clks VF610_CLK_SAI2,
+clks 0, clks 0;
+ clock-names = bus, mclk1, mclk2, mclk3;
dma-names = tx, rx;
dmas = edma0 0 VF610_EDMA_MUXID0_SAI2_TX,
edma0 0 VF610_EDMA_MUXID0_SAI2_RX;
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index d31ce1b..4c3cd59 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -139,8 +139,10 @@
compatible = fsl,vf610-sai;
reg = 0x40031000 0x1000;
interrupts = 0 86 0x04;
- clocks = clks VF610_CLK_SAI2;
- clock-names = sai;
+ clocks = clks VF610_CLK_PLATFORM_BUS,
+ clks VF610_CLK_SAI2,
+ clks 0, clks 0;
+ clock-names = bus, mclk1, mclk2, mclk3;
status = disabled;
};
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index db9f75e..7cd4af9 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -401,7 +401,23 @@ static int fsl_sai_startup(struct snd_pcm_substream
*substream,
struct snd_soc_dai *cpu_dai)
{
struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
- u32 reg;
+ struct device *dev = sai-pdev-dev;
+ u32 reg, i;
+ int ret;
+
+ ret = clk_prepare_enable(sai-bus_clk);
+ if (ret) {
+ dev_err(dev, failed to enable bus clock\n);
+ return ret;
+ }
+
+ for (i = 0; i FSL_SAI_MCLK_MAX; i++) {
+ ret = clk_prepare_enable(sai-mclk_clk[i]);
+ if (ret) {
+ dev_err(dev, failed to enable mclk%d clock\n, i + 1);
+ goto err;
+ }
+ }
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
reg = FSL_SAI_TCR3;
@@ -412,13 +428,20 @@ static int fsl_sai_startup(struct snd_pcm_substream
*substream,
FSL_SAI_CR3_TRCE);
return 0;
+
+err:
+ for (; i 0; i--)
+ clk_disable_unprepare(sai-mclk_clk[i - 1]);
+ clk_disable_unprepare(sai-bus_clk);
+
+ return ret;
}
static void fsl_sai_shutdown(struct snd_pcm_substream *substream,
[PATCH 1/2][powerpc/fsl] Added binding for Freescale CoreNet coherency fabric (CCF)
From: Diana Craciun diana.crac...@freescale.com
The CoreNet coherency fabric is a fabric-oriented, conectivity
infrastructure that enables the implementation of coherent, multicore
systems. The CCF acts as a central interconnect for cores,
platform-level caches, memory subsystem, peripheral devices and I/O host
bridges in the system.
Signed-off-by: Diana Craciun diana.crac...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/ccf.txt| 37 ++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
b/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
new file mode 100644
index 000..61f1a33
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
@@ -0,0 +1,37 @@
+Freescale CoreNet Coherency Fabric(CCF) Device Tree Binding
+
+DESCRIPTION
+
+The CoreNet coherency fabric is a fabric-oriented, connectivity infrastructure
+that enables the implementation of coherent, multicore systems.
+
+Required properties:
+
+- compatible : string
+ fsl,corenet-cf - CoreNet coherency fabric version 1
+ fsl,corenetX-cf - CoreNet coherency fabric version X
+
+- reg : prop-encoded-array
+ A standard property. Specifies the pshysical address and
+ length of the CoreNet coherency fabric memory space.
+
+- interrupts : prop-encoded-array
+ Interrupt mapping for CCF error interrupt.
+
+- fsl,ccf-num-csdids: u32
+ Specifies the number of Coherency Subdomain ID Port Mapping
+ Registers that are supported by the CCF.
+
+- fsl,ccf-num-snoopids: u32
+ Specifies the number of Snoop ID Port Mapping Registers that
+ are supported by CCF.
+
+Example:
+
+ corenet-cf@18000 {
+ compatible = fsl,corenet2-cf;
+ reg = 0x18000 0x1000;
+ interrupts = 16 2 1 31;
+ fsl,ccf-num-csdids = 32;
+ fsl,ccf-num-snoopids = 32;
+ };
--
1.7.11.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2][powerpc/fsl] Updated T4240 corenet-cf node in device tree
From: Diana Craciun diana.crac...@freescale.com
Updated the compatible to reflect that CCF hardware
is different on T4240
Signed-off-by: Diana Craciun diana.crac...@freescale.com
---
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
index f99d74f..e1a8734 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
@@ -343,7 +343,7 @@
};
corenet-cf@18000 {
- compatible = fsl,corenet-cf;
+ compatible = fsl,corenet2-cf;
reg = 0x18000 0x1000;
interrupts = 16 2 1 31;
fsl,ccf-num-csdids = 32;
--
1.7.11.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 1/2] mm: move FAULT_AROUND_ORDER to arch/
On 04/08/2014 06:32 PM, Madhavan Srinivasan wrote: In mm/Kconfig, put config FAULT_AROUND_ORDER int default 1234 if POWERPC default 4 The way you have it now, every single architecture that needs to enable this has to go put that in their Kconfig. That's madness. This way, I though about it and decided not to do this way because, in future, sub platforms of the architecture may decide to change the values. Also, adding an if line for each architecture with different sub platforms oring to it will look messy. I'm not sure why I'm trying here any more. You do seem quite content to add as much cruft to ppc and every other architecture as possible. If your theoretical scenario pops up, you simply do this in ppc: config ARCH_FAULT_AROUND_ORDER int default 999 default 888 if OTHER_SILLY_POWERPC_SUBARCH But *ONLY* in the architectures that care about doing that stuff. You leave every other architecture on the planet alone. Then, in mm/Kconfig: config FAULT_AROUND_ORDER int default ARCH_FAULT_AROUND_ORDER if ARCH_FAULT_AROUND_ORDER default 4 Your way still requires going and individually touching every single architecture's Kconfig that wants to enable fault around. That's not an acceptable solution. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 1/2] mm: move FAULT_AROUND_ORDER to arch/
On 04/09/2014 01:20 AM, Peter Zijlstra wrote: This still misses out on Ben's objection that its impossible to get this right at compile time for many kernels, since they can boot and run on many different subarchs. Completely agree. The Kconfig-time stuff should probably just be a knob to turn it off completely, if anything. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH powerpc] Protect remove_memory() with device hotplug lock
On 04/09/2014 03:54 AM, Li Zhong wrote:
While testing memory hot-remove, I found following dead lock:
Process #1141 is drmgr, trying to remove some memory, i.e. memory499.
It holds the memory_hotplug_mutex, and blocks when trying to remove file
online under dir memory499, in kernfs_drain(), at
wait_event(root-deactivate_waitq,
atomic_read(kn-active) == KN_DEACTIVATED_BIAS);
Process #1120 is trying to online memory499 by
echo 1 memory499/online
In .kernfs_fop_write, it uses kernfs_get_active() to increase
kn-active, thus blocking process #1141. While itself is blocked later
when trying to acquire memory_hotplug_mutex, which is held by process
#1141.
The backtrace of both processes are shown below:
# cat /proc/1120/stack
[c1b18600] 0xc1b18600
[c0015044] .__switch_to+0x144/0x200
[c0263ca4] .online_pages+0x74/0x7b0
[c055b40c] .memory_subsys_online+0x9c/0x150
[c053cbe8] .device_online+0xb8/0x120
[c053cd04] .online_store+0xb4/0xc0
[c0538ce4] .dev_attr_store+0x64/0xa0
[c030f4ec] .sysfs_kf_write+0x7c/0xb0
[c030e574] .kernfs_fop_write+0x154/0x1e0
[c0268450] .vfs_write+0xe0/0x260
[c0269144] .SyS_write+0x64/0x110
[c0009ffc] syscall_exit+0x0/0x7c
# cat /proc/1141/stack
[c1b18600] 0xc1b18600
[c0015044] .__switch_to+0x144/0x200
[c030be14] .__kernfs_remove+0x204/0x300
[c030d428] .kernfs_remove_by_name_ns+0x68/0xf0
[c030fb38] .sysfs_remove_file_ns+0x38/0x60
[c0539354] .device_remove_attrs+0x54/0xc0
[c0539fd8] .device_del+0x158/0x250
[c053a104] .device_unregister+0x34/0xa0
[c055bc14] .unregister_memory_section+0x164/0x170
[c024ee18] .__remove_pages+0x108/0x4c0
[c004b590] .arch_remove_memory+0x60/0xc0
[c026446c] .remove_memory+0x8c/0xe0
[c007f9f4] .pseries_remove_memblock+0xd4/0x160
[c007fcfc] .pseries_memory_notifier+0x27c/0x290
[c08ae6cc] .notifier_call_chain+0x8c/0x100
[c00d858c] .__blocking_notifier_call_chain+0x6c/0xe0
[c071ddec] .of_property_notify+0x7c/0xc0
[c071ed3c] .of_update_property+0x3c/0x1b0
[c00756cc] .ofdt_write+0x3dc/0x740
[c02f60fc] .proc_reg_write+0xac/0x110
[c0268450] .vfs_write+0xe0/0x260
[c0269144] .SyS_write+0x64/0x110
[c0009ffc] syscall_exit+0x0/0x7c
This patch uses lock_device_hotplug() to protect remove_memory() called
in pseries_remove_memblock(), which is also stated before function
remove_memory():
* NOTE: The caller must call lock_device_hotplug() to serialize hotplug
* and online/offline operations before this call, as required by
* try_offline_node().
*/
void __ref remove_memory(int nid, u64 start, u64 size)
With this lock held, the other process(#1120 above) trying to online the
memory block will retry the system call when calling
lock_device_hotplug_sysfs(), and finally find No such device error.
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 573b488..e96357c 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -109,10 +109,12 @@ static int pseries_remove_memblock(unsigned long base,
unsigned int memblock_siz
sections_per_block = block_sz / MIN_MEMORY_BLOCK_SIZE;
nid = memory_add_physaddr_to_nid(base);
+ lock_device_hotplug();
for (i = 0; i sections_per_block; i++) {
remove_memory(nid, base, MIN_MEMORY_BLOCK_SIZE);
base += MIN_MEMORY_BLOCK_SIZE;
}
+ unlock_device_hotplug();
Should we be releasing the lock here? I think we want to hold the lock
until we exit pseries_remove_memblock(). This would ensure that are able
to finish all the work needed to remove memory while holding the lock.
-Nathan
/* Update memory regions for memory remove */
memblock_remove(base, memblock_size);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 01/60] powerpc/powernv: Return secondary CPUs to firmware before FW update
Firmware update on PowerNV platform takes several minutes. During
this time one CPU is stuck in FW and the kernel complains about soft
lockups.
This patch returns all secondary CPUs to firmware before starting
firmware update process.
[ Reworked a bit and cleaned up -- BenH ]
Signed-off-by: Vasant Hegde hegdevas...@linux.vnet.ibm.com
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/opal.h | 1 +
arch/powerpc/platforms/powernv/opal-flash.c | 47 ++---
arch/powerpc/platforms/powernv/setup.c | 25 +--
3 files changed, 66 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 05a23d0..5c34170 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -922,6 +922,7 @@ extern unsigned long opal_get_boot_time(void);
extern void opal_nvram_init(void);
extern int opal_elog_register_init(void);
extern void opal_flash_init(void);
+extern void opal_flash_term_callback(void);
extern int opal_elog_init(void);
extern void opal_platform_dump_init(void);
extern void opal_sys_param_init(void);
diff --git a/arch/powerpc/platforms/powernv/opal-flash.c
b/arch/powerpc/platforms/powernv/opal-flash.c
index 16e571b..11ab43f 100644
--- a/arch/powerpc/platforms/powernv/opal-flash.c
+++ b/arch/powerpc/platforms/powernv/opal-flash.c
@@ -20,6 +20,7 @@
#include linux/mm.h
#include linux/vmalloc.h
#include linux/pagemap.h
+#include linux/delay.h
#include asm/opal.h
@@ -388,11 +389,6 @@ static int opal_flash_update(int op)
(sg-num_entries * sizeof(struct opal_sg_entry) + 16);
}
- pr_alert(FLASH: Image is %u bytes\n, image_data.size);
- pr_alert(FLASH: Image update requested\n);
- pr_alert(FLASH: Image will be updated during system reboot\n);
- pr_alert(FLASH: This will take several minutes. Do not power off!\n);
-
flash:
rc = opal_update_flash(addr);
@@ -400,6 +396,47 @@ invalid_img:
return rc;
}
+/* Return CPUs to OPAL before starting FW update */
+static void flash_return_cpu(void *info)
+{
+ int cpu = smp_processor_id();
+
+ if (!cpu_online(cpu))
+ return;
+
+ /* Disable IRQ */
+ hard_irq_disable();
+
+ /* Return the CPU to OPAL */
+ opal_return_cpu();
+}
+
+/* This gets called just before system reboots */
+void opal_flash_term_callback(void)
+{
+ struct cpumask mask;
+
+ if (update_flash_data.status != FLASH_IMG_READY)
+ return;
+
+ pr_alert(FLASH: Flashing new firmware\n);
+ pr_alert(FLASH: Image is %u bytes\n, image_data.size);
+ pr_alert(FLASH: Performing flash and reboot/shutdown\n);
+ pr_alert(FLASH: This will take several minutes. Do not power off!\n);
+
+ /* Small delay to help getting the above message out */
+ msleep(500);
+
+ /* Return secondary CPUs to firmware */
+ cpumask_copy(mask, cpu_online_mask);
+ cpumask_clear_cpu(smp_processor_id(), mask);
+ if (!cpumask_empty(mask))
+ smp_call_function_many(mask,
+ flash_return_cpu, NULL, false);
+ /* Hard disable interrupts */
+ hard_irq_disable();
+}
+
/*
* Show candidate image status
*/
diff --git a/arch/powerpc/platforms/powernv/setup.c
b/arch/powerpc/platforms/powernv/setup.c
index 1735678..42c16a6 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -98,11 +98,32 @@ static void pnv_show_cpuinfo(struct seq_file *m)
of_node_put(root);
}
+static void pnv_prepare_going_down(void)
+{
+ /*
+* Disable all notifiers from OPAL, we can't
+* service interrupts anymore anyway
+*/
+ opal_notifier_disable();
+
+ /* Soft disable interrupts */
+ local_irq_disable();
+
+ /*
+* Return secondary CPUs to firwmare if a flash update
+* is pending otherwise we will get all sort of error
+* messages about CPU being stuck etc.. This will also
+* have the side effect of hard disabling interrupts so
+* past this point, the kernel is effectively dead.
+*/
+ opal_flash_term_callback();
+}
+
static void __noreturn pnv_restart(char *cmd)
{
long rc = OPAL_BUSY;
- opal_notifier_disable();
+ pnv_prepare_going_down();
while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
rc = opal_cec_reboot();
@@ -119,7 +140,7 @@ static void __noreturn pnv_power_off(void)
{
long rc = OPAL_BUSY;
- opal_notifier_disable();
+ pnv_prepare_going_down();
while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
rc = opal_cec_power_down(0);
--
1.8.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Re: [PATCH v2] powernv: kvm: make _PAGE_NUMA take effect
On Mon, Apr 7, 2014 at 4:36 PM, Alexander Graf ag...@suse.de wrote: On 07.04.14 09:42, Aneesh Kumar K.V wrote: Alexander Graf ag...@suse.com writes: On 03.04.14 04:36, Liu ping fan wrote: Hi Alex, could you help to pick up this patch? since v3.14 kernel can enable numa fault for powerpc. What bad happens without this patch? We map a page even though it was declared to get NUMA migrated? What happens next? Nothing much, we won't be properly accounting the numa access in the host. What we want to achieve is to convert a guest access of the page to a host fault so that we can do proper numa access accounting in the host. This would enable us to migrate the page to the correct numa node. Ok, so no breakages, just less performance. I wouldn't consider it stable material then :). Sorry to reply late, since I am half out of office during this period. I am puzzling about you reply.Without this patch, the guest can NOT sense the numa changes and ask host to put the pages in right place. So the pages which is used by guest will be always misplaced. The numa-fault method is inspired by real requirement to improve performance, so we should also consider the performance drop of guest. Right? Regards, Fan Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fix wrong usage of dmaengine_unmap_put in async_xxx
On Thu, Mar 20, 2014 at 1:16 AM, xuelin@freescale.com wrote: From: Xuelin Shi xuelin@freescale.com dmaengine_unmap_put does below two things: a) unmap pages for srcs and dests b) free unmap struct The unmap struct data is generated but only initialized while other some dma contions are met, like dma alignment etc. If the unmap data is not initialized, call dmaengine_unmap_put will unmap some random data in unmap-addr[...] Actually, this should be fixed by your other patch: https://patchwork.kernel.org/patch/3863711/ Because the to_cnt, from_cnt, are properly initialized to zero. The only issue was that the unmap pool was not specified. Can you verify that the problem still exists with that patch applied? I'll mark it for -stable. Also call dmaengine_get_unmap_data immediatally after generating tx is not correct. Maybe the tx has not been finished by DMA hardware yet but the srcs and dests are dma unmapped. I disagree. It is correct because the unmap data is reference counted. If the DMA hardware is still using the buffers then it must hold a reference on the unmap data. The dmaengine_put_unmap_data() instances your are removing are the ones that drop the initial reference count set in dmaengine_get_unmap_data(). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fix dmaengine_unmap failure
On Wed, Mar 19, 2014 at 11:33 PM, xuelin@freescale.com wrote: From: Xuelin Shi xuelin@freescale.com The count which is used to get_unmap_data maybe not the same as the count computed in dmaengine_unmap which causes to free data in a wrong pool. This patch fixes this issue by keeping the map count with unmap_data structure and use this count to get the pool. Signed-off-by: Xuelin Shi xuelin@freescale.com --- change history: v1: keep mempool pointer with unmap struct v2: keep u8 map_cnt instead of mempool pointer to save mem. Looks good, but please next time remember to prefix your subject line. I.e. dmaengine: fix dmaengine_unmap failure I'll fix this up. -- Dan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
