[PATCH] powerpc: Don't try to set LPCR unless we're in hypervisor mode
Commit 8f619b5429d9 (powerpc/ppc64: Do not turn AIL (reloc-on
interrupts) too early) added code to set the AIL bit in the LPCR
without checking whether the kernel is running in hypervisor mode.
The result is that when the kernel is running as a guest (i.e.,
under PowerKVM or PowerVM), the processor takes a privileged
instruction interrupt at that point, causing a panic. The visible
result is that the kernel hangs after printing returning from
prom_init.
This fixes it by checking for hypervisor mode being available
before setting LPCR. If we are not in hypervisor mode, we enable
relocation-on interrupts later in pSeries_setup_arch using the
H_SET_MODE hcall.
Signed-off-by: Paul Mackerras pau...@samba.org
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
Linus, Ben asked me to send this to you since he's about to be on
vacation, and this bug stops the kernel from booting under a
hypervisor on POWER8 machines. He would like it to go in before rc1.
arch/powerpc/kernel/setup_64.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 3d7a50a..fbe2437 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -201,7 +201,8 @@ static void cpu_ready_for_interrupts(void)
get_paca()-kernel_msr = MSR_KERNEL;
/* Enable AIL if supported */
- if (cpu_has_feature(CPU_FTR_ARCH_207S)) {
+ if (cpu_has_feature(CPU_FTR_HVMODE)
+ cpu_has_feature(CPU_FTR_ARCH_207S)) {
unsigned long lpcr = mfspr(SPRN_LPCR);
mtspr(SPRN_LPCR, lpcr | LPCR_AIL_3);
}
--
1.9.rc1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/7] powerpc/ppc64: Do not turn AIL (reloc-on interrupts) too early
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
Turn them on at the same time as we allow MSR_IR/DR in the paca
kernel MSR, ie, after the MMU has been setup enough to be able
to handle relocated access to the linear mapping.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/kernel/cpu_setup_power.S | 2 --
arch/powerpc/kernel/setup_64.c| 18 +++---
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/cpu_setup_power.S
b/arch/powerpc/kernel/cpu_setup_power.S
index 37d1bb0..1557e7c 100644
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -56,7 +56,6 @@ _GLOBAL(__setup_cpu_power8)
li r0,0
mtspr SPRN_LPID,r0
mfspr r3,SPRN_LPCR
- orisr3, r3, LPCR_AIL_3@h
bl __init_LPCR
bl __init_HFSCR
bl __init_tlb_power8
@@ -75,7 +74,6 @@ _GLOBAL(__restore_cpu_power8)
li r0,0
mtspr SPRN_LPID,r0
mfspr r3,SPRN_LPCR
- orisr3, r3, LPCR_AIL_3@h
bl __init_LPCR
bl __init_HFSCR
bl __init_tlb_power8
BTW with this we can put themfspr r3,SPRN_LPCR in __init_LPCR
and clean this code up bit.
Mikey
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 1d33e81..3d7a50a 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -195,6 +195,18 @@ static void fixup_boot_paca(void)
get_paca()-data_offset = 0;
}
+static void cpu_ready_for_interrupts(void)
+{
+ /* Set IR and DR in PACA MSR */
+ get_paca()-kernel_msr = MSR_KERNEL;
+
+ /* Enable AIL if supported */
+ if (cpu_has_feature(CPU_FTR_ARCH_207S)) {
+ unsigned long lpcr = mfspr(SPRN_LPCR);
+ mtspr(SPRN_LPCR, lpcr | LPCR_AIL_3);
+ }
+}
+
/*
* Early initialization entry point. This is called by head.S
* with MMU translation disabled. We rely on the feature of
@@ -264,9 +276,9 @@ void __init early_setup(unsigned long dt_ptr)
/*
* At this point, we can let interrupts switch to virtual mode
* (the MMU has been setup), so adjust the MSR in the PACA to
- * have IR and DR set.
+ * have IR and DR set and enable AIL if it exists
*/
- get_paca()-kernel_msr = MSR_KERNEL;
+ cpu_ready_for_interrupts();
/* Reserve large chunks of memory for use by CMA for KVM */
kvm_cma_reserve();
@@ -307,7 +319,7 @@ void early_setup_secondary(void)
* (the MMU has been setup), so adjust the MSR in the PACA to
* have IR and DR set.
*/
- get_paca()-kernel_msr = MSR_KERNEL;
+ cpu_ready_for_interrupts();
}
#endif /* CONFIG_SMP */
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 8/8] DMA: Freescale: add suspend resume functions for DMA driver
On 04/10/2014 08:05 PM, Andy Shevchenko wrote:
On Thu, 2014-04-10 at 15:10 +0800, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
This patch adds suspend resume functions for Freescale DMA driver.
.prepare callback is used to stop further descriptors from being added into the
pending queue, and also issue pending queues into execution if there is any.
.suspend callback makes sure all the pending jobs are cleaned up and all the
channels are idle, and save the mode registers.
.resume callback re-initializes the channels by restore the mode registers.
Like we discussed with Vinod [1] the DMA controller drivers should go to
suspend after users and come back before them.
After you reconsider this point the patch logic might be modified a lot.
Looked through that discussions, I really had thought such problem for a
while.
For the dma-controller and dma-user, we don't know which .suspend
callback is executed firstly, so the idea would be: which ever is called
earlier, the dma-controller driver suspend function should be as robust
as possible.
It is better the dma-user .suspend callback is called earlier, some
clean-ups should be done here such as stop dma request, but we cannot
make sure every dma-user has a .suspend callback, some dma-users don't
pay attention to or even don't care the suspend at all for some reason.
So even the suspend_late is used, we cannot assume every dma-user's
activity is cleaned up neatly, dma-controller driver should be robust to
handle this gracefully, that was my design target.
In the prepare() function, clean up the pending queue and stop receive
new coming request, and in the suspend() function I do some register
saving works. I don't think my code needs to be modified much, a
possible change according to Vinod's idea would be:
use .suspend instead of my current .prepare
use . suspend_late instead of my current .suspend
e.g. postpone all my functions to be executed later, this method works
and seems better for client/low-level module drivers.
The reason I didn't use the above functions was that I had read this
Documentation/power/devices.txt, search the definitions of prepare,
suspend, suspend_late and suspend_noirq, I think my usage complies with
that definitions strictly, I can do the modification above if the
maintainer like and if nobody says I break this law.
(Moreover, you abuse your own position to use only setters/getters to
access to the DMAc registers)
My shame, I will update it.
(reason is the setters/getters patch isn't merged into our internal
tree, but this suspend patch has been done. I am trying to sync our
internal kernel and the community now)
[1] http://www.spinics.net/lists/kernel/msg1650974.html
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
drivers/dma/fsldma.c | 100 ++
drivers/dma/fsldma.h | 16
2 files changed, 116 insertions(+)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index c9bf54a..d6da222 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -400,6 +400,14 @@ static dma_cookie_t fsl_dma_tx_submit(struct
dma_async_tx_descriptor *tx)
spin_lock_bh(chan-desc_lock);
+#ifdef CONFIG_PM
+ if (unlikely(chan-pm_state != RUNNING)) {
+ chan_dbg(chan, cannot submit due to suspend\n);
+ spin_unlock_bh(chan-desc_lock);
+ return -1;
+ }
+#endif
+
/*
* assign cookies to all of the software descriptors
* that make up this transaction
@@ -1311,6 +1319,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
INIT_LIST_HEAD(chan-ld_running);
INIT_LIST_HEAD(chan-ld_completed);
chan-idle = true;
+#ifdef CONFIG_PM
+ chan-pm_state = RUNNING;
+#endif
chan-common.device = fdev-common;
dma_cookie_init(chan-common);
@@ -1450,6 +1461,92 @@ static int fsldma_of_remove(struct platform_device *op)
return 0;
}
+#ifdef CONFIG_PM
+static int fsldma_prepare(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct fsldma_device *fdev = platform_get_drvdata(pdev);
+ struct fsldma_chan *chan;
+ int i;
+
+ for (i = 0; i FSL_DMA_MAX_CHANS_PER_DEVICE; i++) {
+ chan = fdev-chan[i];
+ if (!chan)
+ continue;
+
+ spin_lock_bh(chan-desc_lock);
+ chan-pm_state = SUSPENDING;
+ if (!list_empty(chan-ld_pending))
+ fsl_chan_xfer_ld_queue(chan);
+ spin_unlock_bh(chan-desc_lock);
+ }
+
+ return 0;
+}
+
+static int fsldma_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct fsldma_device *fdev = platform_get_drvdata(pdev);
+ struct fsldma_chan *chan;
+ int i;
+
+ for (i = 0; i
Re: [PATCH v3 6/8] DMA: Freescale: change descriptor release process for supporting async_tx
On 04/10/2014 07:56 PM, Andy Shevchenko wrote:
On Thu, 2014-04-10 at 15:10 +0800, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
Fix the potential risk when enable config NET_DMA and ASYNC_TX. Async_tx is
lack of support in current release process of dma descriptor, all descriptors
will be released whatever is acked or no-acked by async_tx, so there is a
potential race condition when dma engine is uesd by others clients (e.g. when
enable NET_DMA to offload TCP).
In our case, a race condition which is raised when use both of talitos and
dmaengine to offload xor is because napi scheduler will sync all pending
requests in dma channels, it affects the process of raid operations due to
ack_tx is not checked in fsl dma. The no-acked descriptor is freed which is
submitted just now, as a dependent tx, this freed descriptor trigger
BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit().
TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0
GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4
0001
GPR08: a7a7a7a7 0001 045/92002 42028042 100a38d4 ed576d98
GPR16: ed5a11b0 2b162000 0200 046/92000 2d555000 ed3015e8
c15a7aa0
GPR24: c155fc40 ecb63220 ecf41d28 e47/92f640bb0 ef640c30
ecf41ca0
NIP [c02b048c] async_tx_submit+0x6c/0x2b4
LR [c02b068c] async_tx_submit+0x26c/0x2b4
Call Trace:
[ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
[ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
[ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
[ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
[ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
[ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
[ecf41f40] [c04329b8] md_thread+0x138/0x16c
[ecf41f90] [c008277c] kthread+0x8c/0x90
[ecf41ff0] [c0011630] kernel_thread+0x4c/0x68
Another modification in this patch is the change of completed descriptors,
there is a potential risk which caused by exception interrupt, all descriptors
in ld_running list are seemed completed when an interrupt raised, it works fine
under normal condition, but if there is an exception occured, it cannot work as
our excepted. Hardware should not be depend on s/w list, the right way is to
read current descriptor address register to find the last completed descriptor.
If an interrupt is raised by an error, all descriptors in ld_running should not
be seemed finished, or these unfinished descriptors in ld_running will be
released wrongly.
A simple way to reproduce:
Enable dmatest first, then insert some bad descriptors which can trigger
Programming Error interrupts before the good descriptors. Last, the good
descriptors will be freed before they are processsed because of the exception
intrerrupt.
Note: the bad descriptors are only for simulating an exception interrupt. This
case can illustrate the potential risk in current fsl-dma very well.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
Signed-off-by: Qiang Liu qiang@freescale.com
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
---
drivers/dma/fsldma.c | 195 --
drivers/dma/fsldma.h | 17 -
2 files changed, 158 insertions(+), 54 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 968877f..f8eee60 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -459,6 +459,87 @@ static struct fsl_desc_sw *fsl_dma_alloc_descriptor(struct
fsldma_chan *chan)
}
/**
+ * fsldma_clean_completed_descriptor - free all descriptors which
+ * has been completed and acked
IIRC the summary should be oneliner.
Check the rest of the code as well.
I don't think so.
See this Documentation/kernel-doc-nano-HOWTO.txt, and you can find this
sentence The short description following the subject can span multiple
lines
+ * @chan: Freescale DMA channel
+ *
+ * This function is used on all completed and acked descriptors.
+ * All descriptors should only be freed in this function.
+ */
+static void fsldma_clean_completed_descriptor(struct fsldma_chan *chan)
+{
+ struct fsl_desc_sw *desc, *_desc;
+
+ /* Run the callback for each descriptor, in order */
+ list_for_each_entry_safe(desc, _desc, chan-ld_completed, node)
+ if (async_tx_test_ack(desc-async_tx))
+ fsl_dma_free_descriptor(chan, desc);
+}
+
+/**
+ * fsldma_run_tx_complete_actions - cleanup a single link descriptor
+ * @chan: Freescale DMA channel
+ * @desc: descriptor to cleanup and free
+ * @cookie: Freescale DMA transaction identifier
+ *
+ * This function is used on a descriptor which has been executed by the DMA
+ * controller. It will run any callbacks, submit any dependencies.
+ */
+static dma_cookie_t fsldma_run_tx_complete_actions(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc, dma_cookie_t cookie)
Maybe you could use cookie as local variable?
Yes.. it doesn't seem good to set a value to input parameter.
Re: [PATCH v3 4/8] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication
On 04/10/2014 07:29 PM, Andy Shevchenko wrote:
On Thu, 2014-04-10 at 15:10 +0800, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
There are several places where descriptors are freed using identical code.
This patch puts this code into a function to reduce code duplication.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
Signed-off-by: Qiang Liu qiang@freescale.com
---
drivers/dma/fsldma.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index b71cc04..b5a0ffa 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -418,6 +418,19 @@ static dma_cookie_t fsl_dma_tx_submit(struct
dma_async_tx_descriptor *tx)
}
/**
+ * fsl_dma_free_descriptor - Free descriptor from channel's DMA pool.
+ * @chan : Freescale DMA channel
+ * @desc: descriptor to be freed
+ */
+static void fsl_dma_free_descriptor(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc)
+{
+ list_del(desc-node);
+ chan_dbg(chan, LD %p free\n, desc);
+ dma_pool_free(chan-desc_pool, desc, desc-async_tx.phys);
+}
+
+/**
* fsl_dma_alloc_descriptor - Allocate descriptor from channel's DMA pool.
* @chan : Freescale DMA channel
*
@@ -489,11 +502,8 @@ static void fsldma_free_desc_list(struct fsldma_chan *chan,
{
struct fsl_desc_sw *desc, *_desc;
- list_for_each_entry_safe(desc, _desc, list, node) {
- list_del(desc-node);
- chan_dbg(chan, LD %p free\n, desc);
- dma_pool_free(chan-desc_pool, desc, desc-async_tx.phys);
- }
+ list_for_each_entry_safe(desc, _desc, list, node)
+ fsl_dma_free_descriptor(chan, desc);
}
static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,
@@ -501,11 +511,8 @@ static void fsldma_free_desc_list_reverse(struct
fsldma_chan *chan,
{
struct fsl_desc_sw *desc, *_desc;
- list_for_each_entry_safe_reverse(desc, _desc, list, node) {
- list_del(desc-node);
- chan_dbg(chan, LD %p free\n, desc);
- dma_pool_free(chan-desc_pool, desc, desc-async_tx.phys);
- }
+ list_for_each_entry_safe_reverse(desc, _desc, list, node)
+ fsl_dma_free_descriptor(chan, desc);
}
/**
@@ -819,8 +826,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan
*chan,
dma_run_dependencies(txd);
dma_descriptor_unmap(txd);
- chan_dbg(chan, LD %p free\n, desc);
- dma_pool_free(chan-desc_pool, desc, txd-phys);
+ fsl_dma_free_descriptor(chan, desc);
Here is no list_del() call since it's been called in dma_do_tasklet().
What will be the result of double list_del() against the same node?
Not clear with your point.
This patch is only introducing a common fsl_dma_free_descriptor() to
reduce code duplication. And later in the patch 6/8 the
fsldma_cleanup_descriptor() is replaced by fsldma_cleanup_descriptorS().
}
/**
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] dmaengine: driver support for FSL RaidEngine device.
From: Xuelin Shi xuelin@freescale.com The RaidEngine is a new FSL hardware used for Raid5/6 acceration. This patch enables the RaidEngine functionality and provides hardware offloading capability for memcpy, xor and pq computation. It works with async_tx. Signed-off-by: Harninder Rai harninder@freescale.com Signed-off-by: Naveen Burmi naveenbu...@freescale.com Signed-off-by: Xuelin Shi xuelin@freescale.com --- changes for v3: - fix memory allocation flag GFP_xxx usage. - add re_jr_issue_pending call in cleanup. - remove unnecessary dma_run_dependencies(...). - use dma_cookie_complete(...) instead of direct updating cookie. drivers/dma/Kconfig| 11 + drivers/dma/Makefile | 1 + drivers/dma/fsl_raid.c | 878 + drivers/dma/fsl_raid.h | 308 + 4 files changed, 1198 insertions(+) create mode 100644 drivers/dma/fsl_raid.c create mode 100644 drivers/dma/fsl_raid.h diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 605b016..829f41c 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -100,6 +100,17 @@ config FSL_DMA EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is on some Txxx and Bxxx parts. +config FSL_RAID +tristate Freescale RAID engine Support +depends on FSL_SOC !FSL_DMA +select DMA_ENGINE +select DMA_ENGINE_RAID +---help--- + Enable support for Freescale RAID Engine. RAID Engine is + available on some QorIQ SoCs (like P5020). It has + the capability to offload memcpy, xor and pq computation + for raid5/6. + config MPC512X_DMA tristate Freescale MPC512x built-in DMA engine support depends on PPC_MPC512x || PPC_MPC831x diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index a029d0f4..60b163b 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -44,3 +44,4 @@ obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o obj-$(CONFIG_TI_CPPI41) += cppi41.o obj-$(CONFIG_K3_DMA) += k3dma.o obj-$(CONFIG_MOXART_DMA) += moxart-dma.o +obj-$(CONFIG_FSL_RAID) += fsl_raid.o diff --git a/drivers/dma/fsl_raid.c b/drivers/dma/fsl_raid.c new file mode 100644 index 000..4b389b1 --- /dev/null +++ b/drivers/dma/fsl_raid.c @@ -0,0 +1,878 @@ +/* + * drivers/dma/fsl_raid.c + * + * Freescale RAID Engine device driver + * + * Author: + * Harninder Rai harninder@freescale.com + * Naveen Burmi naveenbu...@freescale.com + * + * Rewrite: + * Xuelin Shi xuelin@freescale.com + * + * Copyright (c) 2010-2014 Freescale Semiconductor, Inc. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * * Neither the name of Freescale Semiconductor nor the + * names of its contributors may be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * ALTERNATIVELY, this software may be distributed under the terms of the + * GNU General Public License (GPL) as published by the Free Software + * Foundation, either version 2 of that License or (at your option) any + * later version. + * + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * Theory of operation: + * + * General capabilities: + * RAID Engine (RE) block is capable of offloading XOR, memcpy and P/Q + * calculations required in RAID5 and RAID6 operations. RE driver + * registers with Linux's ASYNC layer as dma driver. RE hardware + * maintains strict ordering of the requests through chained + * command queueing. + * + * Data flow: + * Software RAID layer of Linux (MD layer) maintains RAID partitions, + * strips, stripes etc. It sends requests to the underlying AYSNC layer + * which further passes it to RE driver. ASYNC layer
RE: [PATCH v2] fix wrong usage of dmaengine_unmap_put in async_xxx
Hi Dan, With https://patchwork.kernel.org/patch/3863711/ applied, the issue disappeared. Thanks, Xuelin Shi -Original Message- From: dan.j.willi...@gmail.com [mailto:dan.j.willi...@gmail.com] On Behalf Of Dan Williams Sent: 2014年4月10日 12:02 To: Shi Xuelin-B29237 Cc: Koul, Vinod; dmaeng...@vger.kernel.org; linuxppc-dev Subject: 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 v3 6/8] DMA: Freescale: change descriptor release process for supporting async_tx
On 04/11/2014 04:00 PM, Hongbo Zhang wrote:
On 04/10/2014 07:56 PM, Andy Shevchenko wrote:
On Thu, 2014-04-10 at 15:10 +0800, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
Fix the potential risk when enable config NET_DMA and ASYNC_TX.
Async_tx is
lack of support in current release process of dma descriptor, all
descriptors
will be released whatever is acked or no-acked by async_tx, so there
is a
potential race condition when dma engine is uesd by others clients
(e.g. when
enable NET_DMA to offload TCP).
In our case, a race condition which is raised when use both of
talitos and
dmaengine to offload xor is because napi scheduler will sync all
pending
requests in dma channels, it affects the process of raid operations
due to
ack_tx is not checked in fsl dma. The no-acked descriptor is freed
which is
submitted just now, as a dependent tx, this freed descriptor trigger
BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit().
TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0
GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4
0001
GPR08: a7a7a7a7 0001 045/92002 42028042 100a38d4
ed576d98
GPR16: ed5a11b0 2b162000 0200 046/92000 2d555000
ed3015e8 c15a7aa0
GPR24: c155fc40 ecb63220 ecf41d28 e47/92f640bb0
ef640c30 ecf41ca0
NIP [c02b048c] async_tx_submit+0x6c/0x2b4
LR [c02b068c] async_tx_submit+0x26c/0x2b4
Call Trace:
[ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
[ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
[ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
[ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
[ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
[ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
[ecf41f40] [c04329b8] md_thread+0x138/0x16c
[ecf41f90] [c008277c] kthread+0x8c/0x90
[ecf41ff0] [c0011630] kernel_thread+0x4c/0x68
Another modification in this patch is the change of completed
descriptors,
there is a potential risk which caused by exception interrupt, all
descriptors
in ld_running list are seemed completed when an interrupt raised, it
works fine
under normal condition, but if there is an exception occured, it
cannot work as
our excepted. Hardware should not be depend on s/w list, the right
way is to
read current descriptor address register to find the last completed
descriptor.
If an interrupt is raised by an error, all descriptors in ld_running
should not
be seemed finished, or these unfinished descriptors in ld_running
will be
released wrongly.
A simple way to reproduce:
Enable dmatest first, then insert some bad descriptors which can
trigger
Programming Error interrupts before the good descriptors. Last, the
good
descriptors will be freed before they are processsed because of the
exception
intrerrupt.
Note: the bad descriptors are only for simulating an exception
interrupt. This
case can illustrate the potential risk in current fsl-dma very well.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
Signed-off-by: Qiang Liu qiang@freescale.com
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
---
drivers/dma/fsldma.c | 195
--
drivers/dma/fsldma.h | 17 -
2 files changed, 158 insertions(+), 54 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 968877f..f8eee60 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -459,6 +459,87 @@ static struct fsl_desc_sw
*fsl_dma_alloc_descriptor(struct fsldma_chan *chan)
}
/**
+ * fsldma_clean_completed_descriptor - free all descriptors which
+ * has been completed and acked
IIRC the summary should be oneliner.
Check the rest of the code as well.
I don't think so.
See this Documentation/kernel-doc-nano-HOWTO.txt, and you can find
this sentence The short description following the subject can span
multiple lines
+ * @chan: Freescale DMA channel
+ *
+ * This function is used on all completed and acked descriptors.
+ * All descriptors should only be freed in this function.
+ */
+static void fsldma_clean_completed_descriptor(struct fsldma_chan
*chan)
+{
+struct fsl_desc_sw *desc, *_desc;
+
+/* Run the callback for each descriptor, in order */
+list_for_each_entry_safe(desc, _desc, chan-ld_completed, node)
+if (async_tx_test_ack(desc-async_tx))
+fsl_dma_free_descriptor(chan, desc);
+}
+
+/**
+ * fsldma_run_tx_complete_actions - cleanup a single link descriptor
+ * @chan: Freescale DMA channel
+ * @desc: descriptor to cleanup and free
+ * @cookie: Freescale DMA transaction identifier
+ *
+ * This function is used on a descriptor which has been executed by
the DMA
+ * controller. It will run any callbacks, submit any dependencies.
+ */
+static dma_cookie_t fsldma_run_tx_complete_actions(struct
fsldma_chan *chan,
+struct fsl_desc_sw *desc, dma_cookie_t cookie)
Maybe you could use cookie as local variable?
Yes.. it doesn't
[PATCH 0/3] ppc:Set runlatch bits correctly for offline threads and vcpus
The runlatch bits with their value indicated by CTRL_RUNLATCH are set and cleared in the SPRN_CTRL registers to indicate a busy and idle cpu respectively. This is currently being done in the cpuidle path of the host. But needs to be taken care of in hotplug and kvm scenarios. This patchset is aimed at ensuring that the runlatch bits are consisten with the utilization of a CPU under all circumstances. --- Preeti U Murthy (3): ppc/powernv: Set the runlatch bits correctly for offline cpus ppc/kvm: Set the runlatch bit of a CPU just before starting guest ppc/kvm: Clear the runlatch bit of a vcpu before napping arch/powerpc/kvm/book3s_hv_rmhandlers.S | 18 +- arch/powerpc/platforms/powernv/smp.c|3 +++ 2 files changed, 20 insertions(+), 1 deletion(-) -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ASoC: fsl_sai: Use FSL_SAI_xXR() and regmap_update_bits() to simplify code
By doing this, the driver can drop around 50 lines and become neater.
Signed-off-by: Nicolin Chen guangyu.c...@freescale.com
---
sound/soc/fsl/fsl_sai.c | 101
1 file changed, 25 insertions(+), 76 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 5fff2e1..9858d42 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -93,16 +93,8 @@ static int fsl_sai_set_dai_sysclk_tr(struct snd_soc_dai
*cpu_dai,
int clk_id, unsigned int freq, int fsl_dir)
{
struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
- u32 val_cr2, reg_cr2;
-
- if (fsl_dir == FSL_FMT_TRANSMITTER)
- reg_cr2 = FSL_SAI_TCR2;
- else
- reg_cr2 = FSL_SAI_RCR2;
-
- regmap_read(sai-regmap, reg_cr2, val_cr2);
-
- val_cr2 = ~FSL_SAI_CR2_MSEL_MASK;
+ bool tx = fsl_dir == FSL_FMT_TRANSMITTER;
+ u32 val_cr2 = 0;
switch (clk_id) {
case FSL_SAI_CLK_BUS:
@@ -121,7 +113,8 @@ static int fsl_sai_set_dai_sysclk_tr(struct snd_soc_dai
*cpu_dai,
return -EINVAL;
}
- regmap_write(sai-regmap, reg_cr2, val_cr2);
+ regmap_update_bits(sai-regmap, FSL_SAI_xCR2(tx),
+ FSL_SAI_CR2_MSEL_MASK, val_cr2);
return 0;
}
@@ -153,22 +146,10 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai
*cpu_dai,
unsigned int fmt, int fsl_dir)
{
struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
- u32 val_cr2, val_cr4, reg_cr2, reg_cr4;
-
- if (fsl_dir == FSL_FMT_TRANSMITTER) {
- reg_cr2 = FSL_SAI_TCR2;
- reg_cr4 = FSL_SAI_TCR4;
- } else {
- reg_cr2 = FSL_SAI_RCR2;
- reg_cr4 = FSL_SAI_RCR4;
- }
+ bool tx = fsl_dir == FSL_FMT_TRANSMITTER;
+ u32 val_cr2 = 0, val_cr4 = 0;
- regmap_read(sai-regmap, reg_cr2, val_cr2);
- regmap_read(sai-regmap, reg_cr4, val_cr4);
-
- if (sai-big_endian_data)
- val_cr4 = ~FSL_SAI_CR4_MF;
- else
+ if (!sai-big_endian_data)
val_cr4 |= FSL_SAI_CR4_MF;
/* DAI mode */
@@ -189,7 +170,6 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai
*cpu_dai,
* frame sync asserts with the first bit of the frame.
*/
val_cr2 |= FSL_SAI_CR2_BCP;
- val_cr4 = ~(FSL_SAI_CR4_FSE | FSL_SAI_CR4_FSP);
break;
case SND_SOC_DAIFMT_DSP_A:
/*
@@ -199,7 +179,6 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai
*cpu_dai,
* data word.
*/
val_cr2 |= FSL_SAI_CR2_BCP;
- val_cr4 = ~FSL_SAI_CR4_FSP;
val_cr4 |= FSL_SAI_CR4_FSE;
sai-is_dsp_mode = true;
break;
@@ -209,7 +188,6 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai
*cpu_dai,
* frame sync asserts with the first bit of the frame.
*/
val_cr2 |= FSL_SAI_CR2_BCP;
- val_cr4 = ~(FSL_SAI_CR4_FSE | FSL_SAI_CR4_FSP);
sai-is_dsp_mode = true;
break;
case SND_SOC_DAIFMT_RIGHT_J:
@@ -247,23 +225,22 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai
*cpu_dai,
val_cr4 |= FSL_SAI_CR4_FSD_MSTR;
break;
case SND_SOC_DAIFMT_CBM_CFM:
- val_cr2 = ~FSL_SAI_CR2_BCD_MSTR;
- val_cr4 = ~FSL_SAI_CR4_FSD_MSTR;
break;
case SND_SOC_DAIFMT_CBS_CFM:
val_cr2 |= FSL_SAI_CR2_BCD_MSTR;
- val_cr4 = ~FSL_SAI_CR4_FSD_MSTR;
break;
case SND_SOC_DAIFMT_CBM_CFS:
- val_cr2 = ~FSL_SAI_CR2_BCD_MSTR;
val_cr4 |= FSL_SAI_CR4_FSD_MSTR;
break;
default:
return -EINVAL;
}
- regmap_write(sai-regmap, reg_cr2, val_cr2);
- regmap_write(sai-regmap, reg_cr4, val_cr4);
+ regmap_update_bits(sai-regmap, FSL_SAI_xCR2(tx),
+ FSL_SAI_CR2_BCP | FSL_SAI_CR2_BCD_MSTR, val_cr2);
+ regmap_update_bits(sai-regmap, FSL_SAI_xCR4(tx),
+ FSL_SAI_CR4_MF | FSL_SAI_CR4_FSE |
+ FSL_SAI_CR4_FSP | FSL_SAI_CR4_FSD_MSTR, val_cr4);
return 0;
}
@@ -290,29 +267,10 @@ static int fsl_sai_hw_params(struct snd_pcm_substream
*substream,
struct snd_soc_dai *cpu_dai)
{
struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
- u32 val_cr4, val_cr5, val_mr, reg_cr4, reg_cr5, reg_mr;
+ bool tx = substream-stream == SNDRV_PCM_STREAM_PLAYBACK;
unsigned int channels = params_channels(params);
u32 word_width = snd_pcm_format_width(params_format(params));
-
- if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) {
-
[PATCH 0/3] ppc:Set runlatch bits correctly for offline threads and vcpus
The runlatch bits with their value indicated by CTRL_RUNLATCH are set and cleared in the SPRN_CTRL registers to indicate a busy and idle cpu respectively. This is currently being done in the cpuidle path of the host. But needs to be taken care of in hotplug and kvm scenarios. This patchset is aimed at ensuring that the runlatch bits are consisten with the utilization of a CPU under all circumstances. --- Preeti U Murthy (3): ppc/powernv: Set the runlatch bits correctly for offline cpus ppc/kvm: Set the runlatch bit of a CPU just before starting guest ppc/kvm: Clear the runlatch bit of a vcpu before napping arch/powerpc/kvm/book3s_hv_rmhandlers.S | 18 +- arch/powerpc/platforms/powernv/smp.c|3 +++ 2 files changed, 20 insertions(+), 1 deletion(-) -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] ppc/powernv: Set the runlatch bits correctly for offline cpus
Up until now we have been setting the runlatch bits for a busy CPU and
clearing it when a CPU enters idle state. The runlatch bit has thus
been consistent with the utilization of a CPU as long as the CPU is online.
However when a CPU is hotplugged out the runlatch bit is not cleared. It
needs to be cleared to indicate an unused CPU. Hence this patch has the
runlatch bit cleared for an offline CPU just before entering an idle state
and sets it immediately after it exits the idle state.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
Acked-by: Paul Mackerras pau...@samba.org
Reviewed-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/smp.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/smp.c
b/arch/powerpc/platforms/powernv/smp.c
index 908672b..bf5fcd4 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -30,6 +30,7 @@
#include asm/cputhreads.h
#include asm/xics.h
#include asm/opal.h
+#include asm/runlatch.h
#include powernv.h
@@ -156,7 +157,9 @@ static void pnv_smp_cpu_kill_self(void)
*/
mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) ~(u64)LPCR_PECE1);
while (!generic_check_cpu_restart(cpu)) {
+ ppc64_runlatch_off();
power7_nap();
+ ppc64_runlatch_on();
if (!generic_check_cpu_restart(cpu)) {
DBG(CPU%d Unexpected exit while offline !\n, cpu);
/* We may be getting an IPI, so we re-enable
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] ppc/kvm: Set the runlatch bit of a CPU just before starting guest
The secondary threads in the core are kept offline before launching guests in kvm on powerpc: 371fefd6f2dc4666:KVM: PPC: Allow book3s_hv guests to use SMT processor modes. Hence their runlatch bits are cleared. When the secondary threads are called in to start a guest, their runlatch bits need to be set to indicate that they are busy. The primary thread has its runlatch bit set though, but there is no harm in setting this bit once again. Hence set the runlatch bit for all threads before they start guest. Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com Acked-by: Paul Mackerras pau...@samba.org Reviewed-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- arch/powerpc/kvm/book3s_hv_rmhandlers.S |6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S index ffbb871..b254075 100644 --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S @@ -242,6 +242,12 @@ kvm_novcpu_exit: */ .globl kvm_start_guest kvm_start_guest: + + /* Set runlatch bit the minute you wake up from nap */ + mfspr r1, SPRN_CTRLF + ori r1, r1, 1 + mtspr SPRN_CTRLT, r1 + ld r2,PACATOC(r13) li r0,KVM_HWTHREAD_IN_KVM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] ppc/kvm: Clear the runlatch bit of a vcpu before napping
When the guest cedes the vcpu or the vcpu has no guest to run it naps. Clear the runlatch bit of the vcpu before napping to indicate an idle cpu. Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com Acked-by: Paul Mackerras pau...@samba.org Reviewed-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S index b254075..b031f93 100644 --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S @@ -315,6 +315,11 @@ kvm_no_guest: li r0, KVM_HWTHREAD_IN_NAP stb r0, HSTATE_HWTHREAD_STATE(r13) kvm_do_nap: + /* Clear the runlatch bit before napping */ + mfspr r2, SPRN_CTRLF + clrrdi r2, r2, 1 + mtspr SPRN_CTRLT, r2 + li r3, LPCR_PECE0 mfspr r4, SPRN_LPCR rlwimi r4, r3, 0, LPCR_PECE0 | LPCR_PECE1 @@ -2005,8 +2010,13 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_206) /* * Take a nap until a decrementer or external or doobell interrupt -* occurs, with PECE1, PECE0 and PECEDP set in LPCR +* occurs, with PECE1, PECE0 and PECEDP set in LPCR. Also clear the +* runlatch bit before napping. */ + mfspr r2, SPRN_CTRLF + clrrdi r2, r2, 1 + mtspr SPRN_CTRLT, r2 + li r0,1 stb r0,HSTATE_HWTHREAD_REQ(r13) mfspr r5,SPRN_LPCR ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] powerpc: kvm: make _PAGE_NUMA take effect
When we mark pte with _PAGE_NUMA we already call
mmu_notifier_invalidate_range_start
and mmu_notifier_invalidate_range_end, which will mark existing guest hpte
entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new
guest hpte entries.
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
v3:
rebased onto Alex's tree, branch kvm-ppc-next
substitue commit log with the more clear description in Aneesh's reply
(thanks, Aneesh)
---
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index 1d6c56a..1117525 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -234,7 +234,7 @@ long kvmppc_do_h_enter(struct kvm *kvm, unsigned long flags,
pte_size = psize;
pte = lookup_linux_pte_and_update(pgdir, hva, writing,
pte_size);
- if (pte_present(pte)) {
+ if (pte_present(pte)!pte_numa(pte)) {
if (writing !pte_write(pte))
/* make the actual HPTE be read-only */
ptel = hpte_make_readonly(ptel);
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: kvm: make _PAGE_NUMA take effect
On 11.04.2014, at 13:45, Liu Ping Fan pingf...@linux.vnet.ibm.com wrote:
When we mark pte with _PAGE_NUMA we already call
mmu_notifier_invalidate_range_start
and mmu_notifier_invalidate_range_end, which will mark existing guest hpte
entry as HPTE_V_ABSENT. Now we need to do that when we are inserting new
guest hpte entries.
What happens when we don't? Why do we need the check? Why isn't it done
implicitly? What happens when we treat a NUMA marked page as non-present? Why
does it work out for us?
Assume you have no idea what PAGE_NUMA is, but try to figure out what this
patch does and whether you need to cherry-pick it into your downstream kernel.
The description as is still is not very helpful for that. It doesn't even
explain what really changes with this patch applied.
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
v3:
rebased onto Alex's tree, branch kvm-ppc-next
substitue commit log with the more clear description in Aneesh's reply
(thanks, Aneesh)
---
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index 1d6c56a..1117525 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -234,7 +234,7 @@ long kvmppc_do_h_enter(struct kvm *kvm, unsigned long
flags,
pte_size = psize;
pte = lookup_linux_pte_and_update(pgdir, hva, writing,
pte_size);
- if (pte_present(pte)) {
+ if (pte_present(pte)!pte_numa(pte)) {
Spaces missing
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ASoC: fsl_sai: Fix incorrect condition check in trigger()
Patch ASoC: fsl_sai: Fix buggy configurations in trigger() doesn't entirely
fix the condition: FRDE of the current substream direction is being cleared
while the code is still using the non-updated one.
Thus this patch fixes this issue by checking the opposite one's FRDE alone
since the current one's is absolutely disabled.
Signed-off-by: Nicolin Chen guangyu.c...@freescale.com
---
sound/soc/fsl/fsl_sai.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 9858d42..1716a41 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -343,7 +343,8 @@ static int fsl_sai_trigger(struct snd_pcm_substream
*substream, int cmd,
regmap_update_bits(sai-regmap, FSL_SAI_xCSR(tx),
FSL_SAI_CSR_xIE_MASK, 0);
- if (!(tcsr FSL_SAI_CSR_FRDE || rcsr FSL_SAI_CSR_FRDE)) {
+ /* Check if the opposite FRDE is also disabled */
+ if (!(tx ? rcsr FSL_SAI_CSR_FRDE : tcsr FSL_SAI_CSR_FRDE)) {
regmap_update_bits(sai-regmap, FSL_SAI_TCSR,
FSL_SAI_CSR_TERE, 0);
regmap_update_bits(sai-regmap, FSL_SAI_RCSR,
--
1.8.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] dmaengine: driver support for FSL RaidEngine device.
A few more comments:
On Fri, Apr 11, 2014 at 12:41 AM, xuelin@freescale.com wrote:
From: Xuelin Shi xuelin@freescale.com
The RaidEngine is a new FSL hardware used for Raid5/6 acceration.
This patch enables the RaidEngine functionality and provides
hardware offloading capability for memcpy, xor and pq computation.
It works with async_tx.
Signed-off-by: Harninder Rai harninder@freescale.com
Signed-off-by: Naveen Burmi naveenbu...@freescale.com
Signed-off-by: Xuelin Shi xuelin@freescale.com
---
changes for v3:
- fix memory allocation flag GFP_xxx usage.
- add re_jr_issue_pending call in cleanup.
- remove unnecessary dma_run_dependencies(...).
- use dma_cookie_complete(...) instead of direct updating cookie.
drivers/dma/Kconfig| 11 +
drivers/dma/Makefile | 1 +
drivers/dma/fsl_raid.c | 878
+
drivers/dma/fsl_raid.h | 308 +
4 files changed, 1198 insertions(+)
create mode 100644 drivers/dma/fsl_raid.c
create mode 100644 drivers/dma/fsl_raid.h
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 605b016..829f41c 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -100,6 +100,17 @@ config FSL_DMA
EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is on
some Txxx and Bxxx parts.
+config FSL_RAID
+tristate Freescale RAID engine Support
+depends on FSL_SOC !FSL_DMA
This won't work in the case where FSL_DMA=m.
Instead, I think you want to use depends on
!ASYNC_TX_ENABLE_CHANNEL_SWITCH which is the actual dependency.
+select DMA_ENGINE
+select DMA_ENGINE_RAID
+---help---
+ Enable support for Freescale RAID Engine. RAID Engine is
+ available on some QorIQ SoCs (like P5020). It has
+ the capability to offload memcpy, xor and pq computation
+ for raid5/6.
+
[..]
diff --git a/drivers/dma/fsl_raid.c b/drivers/dma/fsl_raid.c
new file mode 100644
index 000..4b389b1
--- /dev/null
+++ b/drivers/dma/fsl_raid.c
@@ -0,0 +1,878 @@
[..]
+void fill_cfd_frame(struct cmpnd_frame *cf, u8 index,
+ size_t length, dma_addr_t addr, bool final)
+{
+ u32 efrl = length CF_LENGTH_MASK;
+ efrl |= final CF_FINAL_SHIFT;
+ cf[index].efrl32 = efrl;
+ cf[index].addr_high = (addr 32) HWDESC_ADDR_HIGH_MASK;
Use upper_32_bits() here otherwise:
drivers/dma/fsl_raid.c: In function 'fill_cfd_frame':
drivers/dma/fsl_raid.c:258:2: warning: right shift count = width of type
+ cf[index].addr_low = (u32)addr;
Use lower_32_bits() here to be symmetrical.
+}
+
+static struct fsl_re_dma_async_tx_desc *re_jr_init_desc(struct re_jr *jr,
+ struct fsl_re_dma_async_tx_desc *desc, void *cf, dma_addr_t paddr)
+{
+ desc-jr = jr;
+ desc-async_tx.tx_submit = re_jr_tx_submit;
+ dma_async_tx_descriptor_init(desc-async_tx, jr-chan);
+ INIT_LIST_HEAD(desc-node);
+
+ desc-hwdesc.fmt32 = FRAME_FORMAT HWDESC_FMT_SHIFT;
+ desc-hwdesc.lbea32 = (paddr 32) HWDESC_ADDR_HIGH_MASK;
Same comment/warning as above...
+ desc-hwdesc.addr_low = (u32)paddr;
ditto.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] dmaengine: driver support for FSL RaidEngine device.
On Fri, Apr 11, 2014 at 10:42 AM, Dan Williams dan.j.willi...@intel.com wrote:
A few more comments:
On Fri, Apr 11, 2014 at 12:41 AM, xuelin@freescale.com wrote:
From: Xuelin Shi xuelin@freescale.com
The RaidEngine is a new FSL hardware used for Raid5/6 acceration.
This patch enables the RaidEngine functionality and provides
hardware offloading capability for memcpy, xor and pq computation.
It works with async_tx.
Signed-off-by: Harninder Rai harninder@freescale.com
Signed-off-by: Naveen Burmi naveenbu...@freescale.com
Signed-off-by: Xuelin Shi xuelin@freescale.com
---
changes for v3:
- fix memory allocation flag GFP_xxx usage.
- add re_jr_issue_pending call in cleanup.
- remove unnecessary dma_run_dependencies(...).
- use dma_cookie_complete(...) instead of direct updating cookie.
drivers/dma/Kconfig| 11 +
drivers/dma/Makefile | 1 +
drivers/dma/fsl_raid.c | 878
+
drivers/dma/fsl_raid.h | 308 +
4 files changed, 1198 insertions(+)
create mode 100644 drivers/dma/fsl_raid.c
create mode 100644 drivers/dma/fsl_raid.h
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 605b016..829f41c 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -100,6 +100,17 @@ config FSL_DMA
EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is
on
some Txxx and Bxxx parts.
+config FSL_RAID
+tristate Freescale RAID engine Support
+depends on FSL_SOC !FSL_DMA
This won't work in the case where FSL_DMA=m.
Instead, I think you want to use depends on
!ASYNC_TX_ENABLE_CHANNEL_SWITCH which is the actual dependency.
+select DMA_ENGINE
+select DMA_ENGINE_RAID
+---help---
+ Enable support for Freescale RAID Engine. RAID Engine is
+ available on some QorIQ SoCs (like P5020). It has
+ the capability to offload memcpy, xor and pq computation
+ for raid5/6.
+
[..]
diff --git a/drivers/dma/fsl_raid.c b/drivers/dma/fsl_raid.c
new file mode 100644
index 000..4b389b1
--- /dev/null
+++ b/drivers/dma/fsl_raid.c
@@ -0,0 +1,878 @@
[..]
+void fill_cfd_frame(struct cmpnd_frame *cf, u8 index,
+ size_t length, dma_addr_t addr, bool final)
+{
+ u32 efrl = length CF_LENGTH_MASK;
+ efrl |= final CF_FINAL_SHIFT;
+ cf[index].efrl32 = efrl;
+ cf[index].addr_high = (addr 32) HWDESC_ADDR_HIGH_MASK;
Use upper_32_bits() here otherwise:
drivers/dma/fsl_raid.c: In function 'fill_cfd_frame':
drivers/dma/fsl_raid.c:258:2: warning: right shift count = width of type
+ cf[index].addr_low = (u32)addr;
Use lower_32_bits() here to be symmetrical.
+}
+
+static struct fsl_re_dma_async_tx_desc *re_jr_init_desc(struct re_jr *jr,
+ struct fsl_re_dma_async_tx_desc *desc, void *cf, dma_addr_t paddr)
+{
+ desc-jr = jr;
+ desc-async_tx.tx_submit = re_jr_tx_submit;
+ dma_async_tx_descriptor_init(desc-async_tx, jr-chan);
+ INIT_LIST_HEAD(desc-node);
+
+ desc-hwdesc.fmt32 = FRAME_FORMAT HWDESC_FMT_SHIFT;
+ desc-hwdesc.lbea32 = (paddr 32) HWDESC_ADDR_HIGH_MASK;
Same comment/warning as above...
+ desc-hwdesc.addr_low = (u32)paddr;
ditto.
Oh, and be mindful of checkpatch output:
ERROR: trailing whitespace
#35: FILE: drivers/dma/Kconfig:106:
+select DMA_ENGINE $
ERROR: trailing whitespace
#42: FILE: drivers/dma/Kconfig:113:
+ $
total: 2 errors, 0 warnings, 1207 lines checked
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] gpio: ge: Convert to platform driver
This patch converts GE I/O FPGA GPIO driver to platform driver.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
drivers/gpio/gpio-ge.c | 174 +++--
1 file changed, 53 insertions(+), 121 deletions(-)
diff --git a/drivers/gpio/gpio-ge.c b/drivers/gpio/gpio-ge.c
index 7b95a4a..1237a73 100644
--- a/drivers/gpio/gpio-ge.c
+++ b/drivers/gpio/gpio-ge.c
@@ -18,15 +18,9 @@
*/
#include linux/kernel.h
-#include linux/compiler.h
-#include linux/init.h
#include linux/io.h
-#include linux/of.h
#include linux/of_device.h
-#include linux/of_platform.h
#include linux/of_gpio.h
-#include linux/gpio.h
-#include linux/slab.h
#include linux/module.h
#define GEF_GPIO_DIRECT0x00
@@ -39,28 +33,26 @@
#define GEF_GPIO_OVERRUN 0x1C
#define GEF_GPIO_MODE 0x20
-static void _gef_gpio_set(void __iomem *reg, unsigned int offset, int value)
+static void gef_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
{
+ struct of_mm_gpio_chip *mmchip = to_of_mm_gpio_chip(chip);
unsigned int data;
- data = ioread32be(reg);
- /* value: 0=low; 1=high */
- if (value 0x1)
- data = data | (0x1 offset);
+ data = ioread32be(mmchip-regs + GEF_GPIO_OUT);
+ if (value)
+ data = data | BIT(offset);
else
- data = data ~(0x1 offset);
-
- iowrite32be(data, reg);
+ data = data ~BIT(offset);
+ iowrite32be(data, mmchip-regs + GEF_GPIO_OUT);
}
-
static int gef_gpio_dir_in(struct gpio_chip *chip, unsigned offset)
{
unsigned int data;
struct of_mm_gpio_chip *mmchip = to_of_mm_gpio_chip(chip);
data = ioread32be(mmchip-regs + GEF_GPIO_DIRECT);
- data = data | (0x1 offset);
+ data = data | BIT(offset);
iowrite32be(data, mmchip-regs + GEF_GPIO_DIRECT);
return 0;
@@ -71,11 +63,11 @@ static int gef_gpio_dir_out(struct gpio_chip *chip,
unsigned offset, int value)
unsigned int data;
struct of_mm_gpio_chip *mmchip = to_of_mm_gpio_chip(chip);
- /* Set direction before switching to input */
- _gef_gpio_set(mmchip-regs + GEF_GPIO_OUT, offset, value);
+ /* Set value before switching to output */
+ gef_gpio_set(mmchip-regs + GEF_GPIO_OUT, offset, value);
data = ioread32be(mmchip-regs + GEF_GPIO_DIRECT);
- data = data ~(0x1 offset);
+ data = data ~BIT(offset);
iowrite32be(data, mmchip-regs + GEF_GPIO_DIRECT);
return 0;
@@ -83,116 +75,56 @@ static int gef_gpio_dir_out(struct gpio_chip *chip,
unsigned offset, int value)
static int gef_gpio_get(struct gpio_chip *chip, unsigned offset)
{
- unsigned int data;
- int state = 0;
struct of_mm_gpio_chip *mmchip = to_of_mm_gpio_chip(chip);
- data = ioread32be(mmchip-regs + GEF_GPIO_IN);
- state = (int)((data offset) 0x1);
-
- return state;
+ return !!(ioread32be(mmchip-regs + GEF_GPIO_IN) BIT(offset));
}
-static void gef_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
-{
- struct of_mm_gpio_chip *mmchip = to_of_mm_gpio_chip(chip);
-
- _gef_gpio_set(mmchip-regs + GEF_GPIO_OUT, offset, value);
-}
+static const struct of_device_id gef_gpio_ids[] = {
+ {
+ .compatible = gef,sbc610-gpio,
+ .data = (void *)19,
+ }, {
+ .compatible = gef,sbc310-gpio,
+ .data = (void *)6,
+ }, {
+ .compatible = ge,imp3a-gpio,
+ .data = (void *)16,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, gef_gpio_ids);
-static int __init gef_gpio_init(void)
+static int __init gef_gpio_probe(struct platform_device *pdev)
{
- struct device_node *np;
- int retval;
- struct of_mm_gpio_chip *gef_gpio_chip;
-
- for_each_compatible_node(np, NULL, gef,sbc610-gpio) {
-
- pr_debug(%s: Initialising GEF GPIO\n, np-full_name);
-
- /* Allocate chip structure */
- gef_gpio_chip = kzalloc(sizeof(*gef_gpio_chip), GFP_KERNEL);
- if (!gef_gpio_chip) {
- pr_err(%s: Unable to allocate structure\n,
- np-full_name);
- continue;
- }
-
- /* Setup pointers to chip functions */
- gef_gpio_chip-gc.of_gpio_n_cells = 2;
- gef_gpio_chip-gc.ngpio = 19;
- gef_gpio_chip-gc.direction_input = gef_gpio_dir_in;
- gef_gpio_chip-gc.direction_output = gef_gpio_dir_out;
- gef_gpio_chip-gc.get = gef_gpio_get;
- gef_gpio_chip-gc.set = gef_gpio_set;
-
- /* This function adds a memory mapped GPIO chip */
- retval = of_mm_gpiochip_add(np, gef_gpio_chip);
- if (retval) {
- kfree(gef_gpio_chip);
