Hi Dan,
I'm OK to save memory here. I'd like to send v2.
Thanks,
Xuelin Shi
-Original Message-
From: Dan Williams [mailto:dan.j.willi...@intel.com]
Sent: 2014年3月19日 23:44
To: Shi Xuelin-B29237
Cc: Vinod Koul; linuxppc-dev; dmaeng...@vger.kernel.org
Subject: Re: [PATCH] fix
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
On Thu, Mar 20, 2014 at 11:03:50AM +0530, Srikar Dronamraju wrote:
Joy,.. let me look at that with ppc in mind.
OK; so while pretty much all the comments from that patch are utter
nonsense (what was I thinking), I cannot actually find a real bug.
But could you try the below which
On 03/20/2014 12:08 AM, Scott Wood wrote:
On Tue, Feb 11, 2014 at 12:50:07PM +0100, Valentin Longchamp wrote:
+reset_cpld@1,0 {
+interrupt-controller;
+#interrupt-cells = 2;
+reg = 1 0 0x80;
+
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,
Yes, this patch is run by checkpatch and found 0 errors, 0 warnings.
-Original Message-
From: Shevchenko, Andriy [mailto:andriy.shevche...@intel.com]
Sent: 2014年3月20日 17:45
To: Shi Xuelin-B29237
Cc: Koul, Vinod; Williams, Dan J; dmaeng...@vger.kernel.org;
linuxppc-dev@lists.ozlabs.org
This problem suggests that we missed a wakeup for a task that was adding
itself to the queue in a wait path. And the only place that can happen
is with the hb spinlock check for any pending waiters. Just in case we
missed some assumption about checking the hash bucket spinlock as a way
of
Hello Johannes,
On 03/19/2014 04:54 PM, Johannes Thumshirn wrote:
On Wed, Mar 19, 2014 at 01:46:37PM +0100, Valentin Longchamp wrote:
Hello,
We have a board that is based on Freescale's P2041 SoC. The boards has 2 PCIe
buses with this topology:
PCIe 0 --- PEX8505 switch --- 4 network
On Tue, Mar 18, 2014 at 06:18:54PM -0500, Scott Wood wrote:
The sequence write, readback, sync will guarantee this according to the
manual.
If you're referring to the section you quoted above, the manual does not
say that. It only talks about when accesses to memory regions affected
From: Kevin Hao
Sent: 20 March 2014 11:48
To: Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org; Chenhui Zhao; jason@freescale.com;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
On Tue, Mar 18, 2014 at 06:18:54PM -0500, Scott Wood
From: Gautham R. Shenoy e...@linux.vnet.ibm.com
Hi,
This is the v3 of the consolidated patchset consisting
patches for enabling cpufreq on IBM POWERNV platforms
along with some enhancements. I have incorporated the review
for v2 (which can be found at [1]).
- This patchset contains code for
From: Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com
Backend driver to dynamically set voltage and frequency on
IBM POWER non-virtualized platforms. Power management SPRs
are used to set the required PState.
This driver works in conjunction with cpufreq governors
like 'ondemand' to provide a
From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
On POWER systems, the CPU frequency is controlled at a core-level and
hence we need to serialize so that only one of the threads in the core
switches the core's frequency at a time.
Using a global mutex lock would needlessly serialize _all_
From: Gautham R. Shenoy e...@linux.vnet.ibm.com
Create a helper routine that can return the cpu-frequency for the
corresponding pstate_id.
Also, cache the values of the pstate_max, pstate_min and
pstate_nominal and nr_pstates in a static structure so that they can
be reused in the future to
From: Gautham R. Shenoy e...@linux.vnet.ibm.com
Create a driver attribute named cpuinfo_nominal_freq which
creates a sysfs read-only file named cpuinfo_nominal_freq. Export
the frequency corresponding to the nominal_pstate through this
interface.
Nominal frequency is the highest non-turbo
From: Gautham R. Shenoy e...@linux.vnet.ibm.com
The current frequency of a cpu is reported through the sysfs file
cpuinfo_cur_freq. This requires the driver to implement a
-get(unsigned int cpu) method which will return the current
operating frequency.
Implement a function named
I noticed KVM is broken when KVM in-kernel XICS emulation
(CONFIG_KVM_XICS) is disabled.
The problem was introduced in 48eaef05 (KVM: PPC: Book3S HV: use
xics_wake_cpu only when defined). It used CONFIG_KVM_XICS to wrap
xics_wake_cpu, where CONFIG_PPC_ICP_NATIVE should have been
used.
2013/7/14 Gerhard Sittig g...@denx.de:
this series
- introduces slave s/g support (that's support for DMA transfers which
involve peripherals in contrast to mem-to-mem transfers)
- adds device tree based lookup support for DMA channels
- combines floating patches and related feedback which
Concentrate the specific code for MPC8308 in the 'if' branch
and handle MPC512x in the 'else' branch.
This modification only reorders instructions but doesn't change behaviour.
Signed-off-by: Alexander Popov a13xp0p0...@gmail.com
Acked-by: Anatolij Gustschin ag...@denx.de
Acked-by: Gerhard Sittig
Introduce support for slave s/g transfer preparation and the associated
device control callback in the MPC512x DMA controller driver, which adds
support for data transfers between memory and peripheral I/O to the
previously supported mem-to-mem transfers.
Signed-off-by: Alexander Popov
Fix mpc_dma_probe() error path and mpc_dma_remove(): manually free IRQs and
dispose IRQ mappings before devm_* takes care of other resources.
Moreover replace devm_request_irq() with request_irq() since there is no need
to use it because the original code always frees IRQ manually with
This patch adds a new common OF dma xlate callback function which will match a
channel by it's id. The binding expects one integer argument which it will use
to
lookup the channel by the id.
Unlike of_dma_simple_xlate this function is able to handle a system with
multiple DMA controllers. When
From: Gerhard Sittig g...@denx.de
introduce a device tree binding document for the MPC512x DMA controller
Signed-off-by: Gerhard Sittig g...@denx.de
[ a13xp0p0...@gmail.com: turn this into a separate patch ]
---
.../devicetree/bindings/dma/mpc512x-dma.txt| 55 ++
1
Register the controller for device tree based lookup of DMA channels
(non-fatal for backwards compatibility with older device trees) and
provide the '#dma-cells' property in the shared mpc5121.dtsi file
Signed-off-by: Gerhard Sittig g...@denx.de
Signed-off-by: Alexander Popov
On Thu, 2014-03-20 at 15:38 +0530, Srikar Dronamraju wrote:
This problem suggests that we missed a wakeup for a task that was adding
itself to the queue in a wait path. And the only place that can happen
is with the hb spinlock check for any pending waiters. Just in case we
missed some
This is mostly useful to make to the boot wrapper code closer with
the kernel code in prom_init.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
arch/powerpc/boot/oflib.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/oflib.c
arch/powerpc/boot/oflib.c:211:9: warning: cast to pointer from integer of \
different size [-Wint-to-pointer-cast]
return (phandle) of_call_prom(finddevice, 1, 1, name);
This is a work around. The definite solution would be to define the
phandle typedef as a u32, as in the
Hi,
The following patchset adds support for 64bit little endian boot
wrapper. It is based on original code from Andrew Tauferner.
The first patches provide fixes for 64bit support. I also changed
the prom code to make it converge with the prom_init kernel code.
They have a lot in common and
Compilation is changed for little endian and entry points between the
wrapper and the kernel are modified to fix endian order with the
FIXUP_ENDIAN trampoline.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
arch/powerpc/boot/Makefile |7 +--
arch/powerpc/boot/crt0.S
This patch adds support a 64bit wrapper entry point. As in 32bit, the
entry point does its own relocation and can be loaded at any address
by the firmware.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
arch/powerpc/boot/crt0.S | 108 --
1 file
This patch fixes warnings when the wrapper is compiled in 64bit and
updates the boot wrapper code related to prom to converge with the
kernel code in prom_init. This should make the review of changes easier.
The kernel has a different number of possible arguments (10) when
entering prom. There
It could certainly be improved using Elf macros and byteswapping
routines, but the initial version of the code is organised to be a
single file program with limited dependencies. yaboot is the same.
Please scream if you want a total rewrite.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
This patch updates the wrapper code to converge with the kernel code in
prom_init.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
arch/powerpc/boot/oflib.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/oflib.c b/arch/powerpc/boot/oflib.c
This patch fixes 64bit compile warnings and updates the wrapper code
to converge the kernel code in prom_init.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
arch/powerpc/boot/of.c|4 ++--
arch/powerpc/boot/of.h|3 ++-
arch/powerpc/boot/oflib.c | 15 ---
3
This patch defines a 'prom' routine similar to 'enter_prom' in the
kernel.
The difference is in the MSR which is built before entering prom. Big
endian order is enforced as in the kernel but 32bit mode is not. It
prepares ground for the next patches which will introduce Little endian
order.
The boot wrapper is now compiled using -m64 for 64bit kernels.
The linker script is generated using the kernel preprocessor flags
to make use of the CONFIG_PPC64 definitions and the wrapper script is
modified to take into account the new elf64ppc format.
zImage is compiled as a position
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
arch/powerpc/boot/main.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index a28f02165e97..46a7464e13c2 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@
When entering the boot wrapper in little endian, we will need to fix
the endian order using a fixup trampoline like in the kernel. This
patch overrides the _zimage_start entry point for this purpose.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
arch/powerpc/boot/Makefile |2 ++
This makes ihandle 64bit friendly.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
arch/powerpc/boot/of.h|2 +-
arch/powerpc/boot/oflib.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/of.h b/arch/powerpc/boot/of.h
index
These are not the most efficient versions of swab but the wrapper does
not do much byte swapping. On a big endian cpu, these routines are
a no-op.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
arch/powerpc/boot/of.h |7 +++
arch/powerpc/boot/swab.h | 29
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
arch/powerpc/boot/elf_util.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/elf_util.c b/arch/powerpc/boot/elf_util.c
index 1567a0c0f05c..316552dea4d8 100644
--- a/arch/powerpc/boot/elf_util.c
+++
When the boot wrapper is compiled in 64bit, there is no need to
use __div64_32.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
arch/powerpc/boot/stdio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/boot/stdio.c b/arch/powerpc/boot/stdio.c
index
Values will need to be byte-swapped when calling prom (big endian) from
a little endian boot wrapper.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
arch/powerpc/boot/of.h|3 +++
arch/powerpc/boot/ofconsole.c |6 --
arch/powerpc/boot/oflib.c | 22
The previous patch broke compatibility for 64bit big endian kernel.
This patch adds a config option to compile the boot wrapper in 64bit
only when CPU_LITTLE_ENDIAN is selected. It restores 32bit compilation
and linking for the big endian kernel.
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
On Wed, 2014-03-19 at 22:56 -0700, Davidlohr Bueso wrote:
On Thu, 2014-03-20 at 11:03 +0530, Srikar Dronamraju wrote:
Joy,.. let me look at that with ppc in mind.
OK; so while pretty much all the comments from that patch are utter
nonsense (what was I thinking), I cannot actually
On Wed, Mar 19, 2014 at 10:56 PM, Davidlohr Bueso davidl...@hp.com wrote:
This problem suggests that we missed a wakeup for a task that was adding
itself to the queue in a wait path. And the only place that can happen
is with the hb spinlock check for any pending waiters.
Ok, so thinking
Hi Cédric,
On Thu, 2014-03-20 at 16:09 +0100, Cédric Le Goater wrote:
16 files changed, 465 insertions(+), 100 deletions(-)
Do you have these in a git branch somewhere so I can merge and test
them?
Thanks.
-Geoff
___
Linuxppc-dev mailing list
On Thu, 2014-03-20 at 09:41 -0700, Linus Torvalds wrote:
On Wed, Mar 19, 2014 at 10:56 PM, Davidlohr Bueso davidl...@hp.com wrote:
This problem suggests that we missed a wakeup for a task that was adding
itself to the queue in a wait path. And the only place that can happen
is with the hb
On Thu, Mar 20, 2014 at 10:18 AM, Davidlohr Bueso davidl...@hp.com wrote:
It strikes me that the spin_is_locked() test has no barriers wrt the
writing of the new futex value on the wake path. And the read barrier
obviously does nothing wrt the write either. Or am I missing
something? So the
On Thu, 2014-03-20 at 10:42 -0700, Linus Torvalds wrote:
On Thu, Mar 20, 2014 at 10:18 AM, Davidlohr Bueso davidl...@hp.com wrote:
It strikes me that the spin_is_locked() test has no barriers wrt the
writing of the new futex value on the wake path. And the read barrier
obviously does
On Thu, Mar 20, 2014 at 11:03 AM, Davidlohr Bueso davidl...@hp.com wrote:
I still wonder about ppc and spinlocks (no ticketing!!) ... sure the
waiters patch might fix the problem just because we explicitly count
the members of the plist. And I guess if we cannot rely on all archs
having an
On Thu, Mar 20, 2014 at 10:18 AM, Davidlohr Bueso davidl...@hp.com wrote:
Comparing with the patch I sent earlier this morning, looks equivalent,
and fwiw, passes my initial qemu bootup, which is the first way of
detecting anything stupid going on.
So, Srikar, please try this patch out, as
On Thu, 2014-03-20 at 11:36 -0700, Linus Torvalds wrote:
On Thu, Mar 20, 2014 at 10:18 AM, Davidlohr Bueso davidl...@hp.com wrote:
Comparing with the patch I sent earlier this morning, looks equivalent,
and fwiw, passes my initial qemu bootup, which is the first way of
detecting anything
On Thu, Mar 20, 2014 at 12:08 PM, Davidlohr Bueso davidl...@hp.com wrote:
Oh, it does. This atomics technique was tested at a customer's site and
ready for upstream.
I'm not worried about the *original* patch. I'm worried about the
incremental one.
Your original patch never applied to my tree
On Thu, 2014-03-20 at 12:25 -0700, Linus Torvalds wrote:
On Thu, Mar 20, 2014 at 12:08 PM, Davidlohr Bueso davidl...@hp.com wrote:
Oh, it does. This atomics technique was tested at a customer's site and
ready for upstream.
I'm not worried about the *original* patch. I'm worried about the
On Thu, 2014-03-20 at 09:31 -0700, Davidlohr Bueso wrote:
hmmm looking at ppc spinlock code, it seems that it doesn't have ticket
spinlocks -- in fact Torsten Duwe has been trying to get them upstream
very recently. Since we rely on the counter for detecting waiters, this
might explain the
On Thu, Mar 20, 2014 at 1:20 PM, Davidlohr Bueso davidl...@hp.com wrote:
I reverted commits 99b60ce6 (documentation) and b0c29f79 (the offending
commit), and then I cleanly applied the equivalent ones from v3 of the
series (which was already *tested* and ready for upstream until you
suggested
On Thu, 2014-03-20 at 09:42 +0100, Valentin Longchamp wrote:
On 03/20/2014 12:08 AM, Scott Wood wrote:
On Tue, Feb 11, 2014 at 12:50:07PM +0100, Valentin Longchamp wrote:
+ reset_cpld@1,0 {
+ interrupt-controller;
+ #interrupt-cells = 2;
+
On Thu, 2014-03-20 at 11:59 +, David Laight wrote:
I tried to work out what the 'twi, isync' instructions were for (in
in_le32()).
The best I could come up with was to ensure a synchronous bus-fault.
But bus faults are probably only expected during device probing - not
normal operation,
On Thu, 2014-03-20 at 19:47 +0800, Kevin Hao wrote:
OK, so the intention of 'twi, isync' following the load is not to order the
following storage access, but order the following delay loop instructions,
right? But according to the e6500 manual, the instructions complete in order.
The following
On Wed, 2014-03-19 at 08:56 +0800, Chenhui Zhao wrote:
On Tue, Mar 18, 2014 at 05:42:09PM -0500, Scott Wood wrote:
On Mon, 2014-03-17 at 19:19 +0800, Chenhui Zhao wrote:
On Fri, Mar 14, 2014 at 06:18:27PM -0500, Scott Wood wrote:
Why do you need the entry mapping on 32-bit but not
On 03/10/2014 04:42 PM, Sudeep Holla wrote:
Hi Anshuman,
On 07/03/14 06:14, Anshuman Khandual wrote:
On 03/07/2014 09:36 AM, Anshuman Khandual wrote:
On 02/19/2014 09:36 PM, Sudeep Holla wrote:
From: Sudeep Holla sudeep.ho...@arm.com
This patch removes the redundant sysfs cacheinfo code
Ok, so a big reason why this patch doesn't apply cleanly after reverting
is because *most* of the changes were done at the top of the file with
regards to documenting the ordering guarantees, the actual code changes
are quite minimal.
I reverted commits 99b60ce6 (documentation) and
On Thu, Mar 20, 2014 at 9:55 PM, Srikar Dronamraju
sri...@linux.vnet.ibm.com wrote:
I reverted commits 99b60ce6 and b0c29f79. Then applied the patches in
the above url. The last one had a reject but it was pretty
straightforward to resolve it. After this, specjbb completes.
So reverting and
64 matches
Mail list logo
