* Arnaldo Carvalho de Melo a...@infradead.org wrote:
From: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Hi Ingo,
Please consider pulling,
Regards,
- Arnaldo
The following changes since commit e5302920da9ef23f9d19d4e9ac85704cc25bee7a:
perf: Fix interrupt handler
On Fri, 2013-07-12 at 13:36 +0800, Kevin Hao wrote:
+ /*
+* If we support a HW FPU, we need to ensure the FP state
+* if flushed into the thread_struct before attempting
+* emulation
+*/
+#ifdef CONFIG_PPC_FPU
+ flush_fp_to_thread(current);
On Thu, Jul 11, 2013 at 11:00:15PM -0500, Timur Tabi wrote:
Nicolin Chen wrote:
If I'm not missing some part of branch updating, it looks like Mark hasn't
pushed it to the branch yet.
Please test it for me. Thank you.
I definitely want to. Unfortunately, I'm literally in the middle of
2013/7/10 Gerhard Sittig g...@denx.de:
Disclaimer: It's been a while since I worked with the MPC512x
DMA controller, and I only read the RM rev3 back then.
Hello Gerhard.
Thank you for fast and detailed feedback.
@@ -256,7 +256,9 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
Hello Gerhard
Thanks for the review.
I'll do my best to answer your questions and fix my code.
2013/7/10 Gerhard Sittig g...@denx.de:
On Wed, Jul 10, 2013 at 14:21 +0400, Alexander Popov wrote:
+/*
+ * SCLPC Module (LPB FIFO)
+ */
+enum lpb_dev_portsize {
+ LPB_DEV_PORTSIZE_UNDEFINED
Moderator..can you change the subject of this to Understanding register
usage as per ABI rules for functions ??
Additionally, doesn't anyone have anything to say about this?
--
View this message in context:
Mark Brown wrote:
Yes, that's why I just went ahead - you'd said recently that you'd be
out of action for a while and not able to test anything.
Yeah, I'd rather you waited until I at least made sure it compiled. Is
there any way you can at least install the Freescale PowerPC SDK and do
[ adding Lars to Cc: since we talk about OF-DMA ]
I put your DMA part of the series into a local test setup, and
slightly modified it in the suggested ways. This may not suffice
for a Tested-By attribute, since it did not test your LPB part
and did not use your original patch. But it verified
On Fri, Jul 12, 2013 at 07:11:35AM -0500, Timur Tabi wrote:
Mark Brown wrote:
Yes, that's why I just went ahead - you'd said recently that you'd be
out of action for a while and not able to test anything.
Yeah, I'd rather you waited until I at least made sure it compiled.
Is there any way
On Fri, Jul 12, 2013 at 07:11:35AM -0500, Timur Tabi wrote:
Mark Brown wrote:
Yes, that's why I just went ahead - you'd said recently that you'd be
out of action for a while and not able to test anything.
Yeah, I'd rather you waited until I at least made sure it compiled.
Is there any way
blurb is below the stats
Alexander Popov (1):
powerpc: mpc512x_dma: add support for data transfers between memory
and i/o memory
Gerhard Sittig (6):
dma: mpc512x: fix start condition in execute()
dma: mpc512x: support 'terminate all' control request
dts: mpc512x: prepare for
From: Alexander Popov a13xp0p0...@gmail.com
From: Alexander Popov a13xp0p0...@gmail.com
Data transfers between memory and i/o memory require more delicate TCD
(Transfer Control Descriptor) configuration and DMA channel service requests
via hardware.
dma_device.device_control callback function
adjust the conditions how submitted DMA jobs get started: memory transfers
need to get initiated by an explicit software request, all transfers which
involve peripherals need to reference the external requester line
Signed-off-by: Gerhard Sittig g...@denx.de
---
drivers/dma/mpc512x_dma.c |4
implement the TERMINATE_ALL request in the device_control() callback
of the DMA engine driver for the MPC512x DMA controller
reword variable initialization to better follow the code path and to
avoid artificial diffs later on (this style change vanishes when this
patch gets squashed with the
prepare C preprocessor support when processing MPC512x DTS files
- switch from DTS syntax to CPP syntax for include specs
- create a symlink such that DTS processing can reference includes
Signed-off-by: Gerhard Sittig g...@denx.de
---
arch/powerpc/boot/dts/ac14xx.dts |2 +-
for the DMA controller of the MPC512x SoC, DMA channels directly
correspond to specific peripherals, since requester lines directly map
to channels while no additional flexibility or mapping is involved
introduce a dt-bindings header file for MPC512x DMA channels, and make
the shared DT specs in
register the controller for device tree based lookup of DMA channels
(non-fatal for backwards compatibility with older device trees), provide
the '#dma-cells' property in the shared mpc5121.dtsi file, and introduce
a bindings document for the MPC512x DMA controller
Signed-off-by: Gerhard Sittig
From: Lars-Peter Clausen l...@metafoo.de
From: Lars-Peter Clausen l...@metafoo.de
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
QD HACK to enable SD card support without correct COMMON_CLK support,
best viewed with 'git diff -w -b', NOT acceptable for mainline (NAKed)
Signed-off-by: Gerhard Sittig g...@denx.de
---
drivers/mmc/host/mxcmmc.c | 41 +++--
1 file changed, 27
On Fri, Jul 12, 2013 at 14:14 +0200, Gerhard Sittig wrote:
We shall combine the parts which currently are floating around.
So that others aren't supposed to pick up pieces but instead can
use a series and get something consistent.
Here are the parts that I'm aware of:
- Anatolij's work
Hi all,
I'm trying to build current mainline git with gcc version 4.4.1 as a
cross compiler and I'm getting the following:
CC arch/powerpc/kernel/ptrace.o
{standard input}: Assembler messages:
{standard input}:1619: Error: junk at end of line: `1'
{standard input}:2074: Error: junk at
On 07/12/2013 05:26 PM, Gerhard Sittig wrote:
[...]
Lars, there is a checkpatch warning about a line longer than 80
characters in the common xlate part -- I didn't dare to change your
submission, and the part included here is verbatim from your patchwork
2331091 (original submission) and
On 07/11/2013 09:25:12 PM, Kevin Hao wrote:
On Thu, Jul 11, 2013 at 09:30:02AM -0500, Scott Wood wrote:
Sorry, that was my fault -- for some reason I didn't see that when I
grepped for PPC_WARN_EMULATED looking for math stuff, and thus
requested it be added. In any case, I don't see why it
On 07/11/2013 07:08:58 PM, Haijun Zhang wrote:
Overview of P1020RDB-PD device:
- DDR3 2GB
- NOR flash 64MB
- NAND flash 128MB
- SPI flash 16MB
- I2C EEPROM 256Kb
- eTSEC1 (RGMII PHY) connected to VSC7385 L2 switch
- eTSEC2 (SGMII PHY)
- eTSEC3 (RGMII PHY)
- SDHC
- 1 USB ports
- TDM ports
- PCIe
On 07/11/2013 07:21 PM, Michael Ellerman wrote:
On Thu, Jul 11, 2013 at 03:22:49PM -0600, Chris Friesen wrote:
On 07/11/2013 02:55 PM, Chris Friesen wrote:
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system
with 8GB of memory. (It's an embedded system and I can't do
On 07/11/2013 11:58:08 PM, Dongsheng Wang wrote:
+ /* Invalidate all tlbs */
+ bl _tlbil_all
Again, this will break on non-booke.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On 07/11/2013 11:04:23 PM, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, July 11, 2013 5:43 AM
To: Wang Dongsheng-B40534
Cc: Wang Dongsheng-B40534; b...@kernel.crashing.org; Wood
Scott-B07421;
johan...@sipsolutions.net;
On Fri, Jul 12, 2013 at 10:27:41AM -0600, Chris Friesen wrote:
Hi all,
I'm trying to build current mainline git with gcc version 4.4.1 as a
cross compiler and I'm getting the following:
CC arch/powerpc/kernel/ptrace.o
{standard input}: Assembler messages:
{standard input}:1619:
On 07/12/2013 03:08 PM, Chris Friesen wrote:
I turned on the instrumentation in early_init_dt_scan_memory() and got
the following when jumping to the capture kernel:
memory scan node memory, reg size 16, data: 0 0 2 0,
- 0 , 2
That 0x2 matches the fact that I'm seeing 8GB of
On Fri, 2013-07-12 at 10:27 -0600, Chris Friesen wrote:
Hi all,
I'm trying to build current mainline git with gcc version 4.4.1 as a
cross compiler and I'm getting the following:
CC arch/powerpc/kernel/ptrace.o
{standard input}: Assembler messages:
{standard input}:1619:
On Fri, 2013-07-12 at 15:53 -0500, Scott Wood wrote:
It's not redundant at all to warn when an FPU is absent. It tells you
that you're being slowed down by running hard-FP code instead of
soft-FP code.
Right, just warn always.
Ben.
___
On Fri, 2013-07-12 at 16:54 -0500, Scott Wood wrote:
set_context() doesn't exist for hash MMUs.
Whatever you do, please try actually building it on various targets,
including both 32 and 64 bits, and both hash and non-hash. And make
sure that whatever effect PPC32 was depending on
On Mon, Jul 08, 2013 at 12:18:39PM -0500, Scott Wood wrote:
On 07/08/2013 02:16:04 AM, Haijun Zhang wrote:
On T4240QDS board controllers has an unusable ADMA engine, so use
SDMA instead.
Also 3.0v is support on T4240QDS board even if the capacity
detailed only 1.8v
support. Without this
On Thu, Jul 11, 2013 at 08:21:54PM +0800, Kevin Hao wrote:
By doing this we can make sure that the FPU state is only flushed to
the thread struct when it is really needed.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/kernel/traps.c | 9 -
On 07/12/2013 04:31 PM, Tony Breeds wrote:
On Fri, Jul 12, 2013 at 10:27:41AM -0600, Chris Friesen wrote:
Hi all,
I'm trying to build current mainline git with gcc version 4.4.1 as a
cross compiler and I'm getting the following:
CC arch/powerpc/kernel/ptrace.o
{standard input}:
Erratum A-006598 says that 64-bit mftb is not atomic -- it's subject
to the same race condition as doing mftbu/mftbl on 32-bit, thus we
need to use the same loop to safely read it.
This deals with kernel and vdso accesses, but other userspace accesses
will of course need to be fixed elsewhere.
From: Wood Scott-B07421
Sent: Saturday, July 13, 2013 5:49
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-B40534
Subject: Re: [PATCH v2 1/2] powerpc: add Book E support to 64-bit hibernation
On 07/11/2013 11:58:08 PM, Dongsheng Wang
The presence or absence of EBB is advertised to userspace via the presence
or absence of PPC_FEATURE2_EBB in cpu_user_features2.
Because the kernel can be built without PMU support, we should only add
PPC_FEATURE2_EBB to cpu_user_features2 when we successfully register the
power8 PMU support.
38 matches
Mail list logo
