On Sunday 10 January 2010 21:51:42 Benjamin Herrenschmidt wrote:
> It seems that in qemu, we can see an interrupt in R3 despite the
> fact that it's masked in W1. The chip doesn't actually issue an
> interrupt, but we can "see" it when taking an interrupt for the
> other channel. This may be a qemu
Hello Felix,
I had a problem similar to this on the 440GX, the PCI code was not
sending type 1 transactions when scanning behind bridges. Perhaps you
could try this:
Index: linux/arch/powerpc/sysdev/ppc4xx_pci.c
===
--- linux/arch/po
On Mon, Jan 11, 2010 at 11:47:37AM +0800, Wu Jiajun-B06378 wrote:
>
> 'bd == ugeth->txBd[txQ]' has two possible statuses: 1)full queue.
> 2)empty queue.
> Removing 'netif_queue_stopped() == 0' will make transmitting stopping
> when the queue is full.
>
> I made a new patch for this oops.
[...]
On Thu, Jan 07, 2010 at 11:23:57AM +0100, Peter Korsgaard wrote:
> Commit 4c1fba44296 (Add support for QE DMA mode and CPM1/CPM2 chips)
> added unconditional calls to _cpm_init() / _cpm_free() from
> probe()/remove(), but only checked if we're actually using CPM mode
> in _init(), causing the WARN_
Hi Stef,
Stef van Os wrote:
Hello Felix,
I had a problem similar to this on the 440GX, the PCI code was not
sending type 1 transactions when scanning behind bridges. Perhaps you
could try this:
Index: linux/arch/powerpc/sysdev/ppc4xx_pci.c
==
Yes,'if (!skb)' is enough.
You can reproduce transmitting stopping if you use 'if ((bd ==
ugeth->txBd[txQ])' and run ipforwarding with MTU=64 1Gbps 100%linerate.
-Original Message-
From: Anton Vorontsov [mailto:avoront...@ru.mvista.com]
Sent: 2010年1月11日 18:53
To: Wu Jiajun-B06378
Cc: l
The following series implements some minor fixes and updates to the GE
SBC310, SBC610 and PPC9A
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales
Tove Valley Business Park, Towcester,
Add the MSI section to the DTS file for the GE SBC310.
Signed-off-by: Martyn Welch
---
arch/powerpc/boot/dts/gef_sbc310.dts | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc310.dts
b/arch/powerpc/boot/dts/gef_sbc310.dts
index
From: Malcolm Crossley
Correction to interrupt map mask for GE SBC310 XMC site and addition of
alias.
Signed-off-by: Malcolm Crossley
Signed-off-by: Martyn Welch
---
arch/powerpc/boot/dts/gef_sbc310.dts |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/b
From: Malcolm Crossley
Add the MSI section to the DTS file for the GE SBC610.
Signed-off-by: Malcolm Crossley
Signed-off-by: Martyn Welch
---
arch/powerpc/boot/dts/gef_sbc610.dts | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/ge
Support for the SBC610 VPX Single Board Computer from GE (PowerPC MPC8641D).
This patch adds basic support for the on-board flash.
Signed-off-by: Martyn Welch
---
arch/powerpc/boot/dts/gef_sbc610.dts | 50
arch/powerpc/configs/86xx/gef_sbc610_defconfig |
Signed-off-by: Martyn Welch
---
arch/powerpc/configs/86xx/gef_sbc610_defconfig |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/configs/86xx/gef_sbc610_defconfig
b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
index 9284f04..4912602 100644
--- a/arch/powe
From: Malcolm Crossley
Add the MSI section to the DTS file for the GE PPC9A.
Signed-off-by: Malcolm Crossley
Signed-off-by: Martyn Welch
---
arch/powerpc/boot/dts/gef_ppc9a.dts | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/b
Enable the VME driver (which is currently in staging) on the PPC9A
Signed-off-by: Martyn Welch
---
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 47 -
1 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig
b/arc
Enable the VME driver (which is currently in staging) on the SBC610.
Signed-off-by: Martyn Welch
---
arch/powerpc/configs/86xx/gef_sbc610_defconfig | 39 +++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/configs/86xx/gef_sbc610_defconfig
b/
This patch ports the kprobe-based event tracer to powerpc. This patch
is based in x86 port. This brings powerpc on par with x86.
ChangeLog - v2:
- Removed regs_get_argument_nth() API as function argument access syntax
is dropped from kprobe-tracer. Please refer to patches below on Linux PPC
ma
On Mon, Jan 11, 2010 at 11:17:04AM +0530, Dudhat Dipen-B09055 wrote:
>
> Hi Ira,
>
> I have tested your patches with async DMA memcpy support. Though I
> haven't captured the improvement figures.
> It works fine for RAID5 memcpy offload as interrupts are coming for
> separate DMA channels while I
Hi Stef
Felix Radensky wrote:
Hi Stef,
Stef van Os wrote:
Hello Felix,
I had a problem similar to this on the 440GX, the PCI code was not
sending type 1 transactions when scanning behind bridges. Perhaps you
could try this:
Index: linux/arch/powerpc/sysdev/ppc4xx_pci.c
==
Hi Roman.
I'm finally getting some time to look at these with a bit more detail.
On Mon, Dec 21, 2009 at 11:57 PM, Roman Fietze
wrote:
>
> Signed-off-by: Roman Fietze
> ---
> arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 18 +-
> 1 files changed, 9 insertions(+), 9 deletion
On Mon, Dec 21, 2009 at 11:59 PM, Roman Fietze
wrote:
No patch description? Very few patches are sufficiently described by
the subject line alone. Tell me what the problem is, what the patch
changes, and why.
> Signed-off-by: Roman Fietze
> ---
> arch/powerpc/include/asm/mpc52xx.h
On Tue, Dec 22, 2009 at 12:00 AM, Roman Fietze
wrote:
>
This should probably be merged with the first patch to actually use
the bit definitions. More comments below.
> Signed-off-by: Roman Fietze
> ---
> arch/powerpc/include/asm/mpc52xx.h | 40 +++
> 1 files
Grant Likely wrote:
Please don't. I know that a lot of other 5200 code uses register map
structures in this way, but I consider it bad practice. I coded this
driver without a structure for a reason. The reason I haven't removed
the other 5200 register map structures is the code impact would be
On Tue, Dec 22, 2009 at 12:01 AM, Roman Fietze
wrote:
>
> Use SCLPC bit definitions from mpc52xx.h for better readability.
The changes of is_write etc. are intermingled with the functional
changes being made. The functional behaviour of this thing is subtle,
and I'd prefer the stylistic stuff ha
On Tue, Dec 22, 2009 at 12:04 AM, Roman Fietze
wrote:
>
> Signed-off-by: Roman Fietze
Yes, this is definitely needed. Please respin this patch and move it
earlier in your series so I can apply it to mainline.
More comments below.
g.
> ---
> arch/powerpc/include/asm/mpc52xx.h |
On Mon, Jan 11, 2010 at 12:42 PM, Scott Wood wrote:
> Grant Likely wrote:
>>
>> Please don't. I know that a lot of other 5200 code uses register map
>> structures in this way, but I consider it bad practice. I coded this
>> driver without a structure for a reason. The reason I haven't removed
>
On Tue, Dec 22, 2009 at 12:05 AM, Roman Fietze
wrote:
>
Again, need a description as to 'why?'
> Signed-off-by: Roman Fietze
> ---
> arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52x
On Tue, Dec 22, 2009 at 12:06 AM, Roman Fietze
wrote:
>
Need patch description
> Signed-off-by: Roman Fietze
> ---
> arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 40
> -
> 1 files changed, 26 insertions(+), 14 deletions(-)
>
> diff --git a/arch/powerpc/platforms/5
Guys:
A platform I have inherited utilizes a GPIO on an I2C expander chip
(MAX7314) as a SPI slave-select. I'm using the actual MPC52xx SPI
peripheral, not a PSC.
It looks like the current version of the MPC52xx SPI driver won't work
with sleep-capable GPIOs for slave-selects. In particular, i
On Tue, Dec 22, 2009 at 12:08 AM, Roman Fietze
wrote:
>
> Signed-off-by: Roman Fietze
> ---
> arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 33
> +++--
> 1 files changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
>
On Tue, Dec 22, 2009 at 12:09 AM, Roman Fietze
wrote:
>
> The order of the raised interrupts of SCLPC and BCOM cannot be
> predicted, because it depends on the individual BCOM and CPU loads. So
> in DMA mode we just wait for both until we finish the transaction.
I'm really not convinced. It is t
On Tue, Dec 22, 2009 at 12:10 AM, Roman Fietze
wrote:
>
> Signed-off-by: Roman Fietze
Please merge this change with the patch that adds the dma mapping
g.
> ---
> arch/powerpc/include/asm/mpc52xx.h | 1 -
> arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 13 +++--
> 2
On Tue, Dec 22, 2009 at 12:13 AM, Roman Fietze
wrote:
>
> Signed-off-by: Roman Fietze
If this description is no longer correct, then you must also add
comments describing the new behaviour.
Thanks for all the work on this. I hope I haven't been too brutal on
my comments, but this device is sub
Dear Grant,
In message you
wrote:
>
> Please don't. I know that a lot of other 5200 code uses register map
> structures in this way, but I consider it bad practice. I coded this
May I ask _why_ you consider this bad practice?
Is a structure not the most natural way to encode the specifics o
Dear Grant Likely,
In message you
wrote:
>
> > /* mpc52xx_lpbfifo.c */
> > #define MPC52XX_LPBFIFO_FLAG_READ (0)
> > -#define MPC52XX_LPBFIFO_FLAG_WRITE (1<<0)
> > -#define MPC52XX_LPBFIFO_FLAG_NO_INCREMENT (1<<1)
> > -#define MPC52XX_LPBFIFO_FLAG_NO_DMA
> It seems I was wrong. I've manually applied the patch at the wrong
> place. After patching the correct function
> I'm not getting hard resets any more, which is a great improvement !
> Thanks a lot, I really appreciate your help !
This is somewhat funny... I wonder how it would have managed to
On Mon, Jan 11, 2010 at 1:43 PM, Wolfgang Denk wrote:
> Dear Grant,
>
> In message you
> wrote:
>>
>> Please don't. I know that a lot of other 5200 code uses register map
>> structures in this way, but I consider it bad practice. I coded this
>
> May I ask _why_ you consider this bad practice?
Hi, Ben
Benjamin Herrenschmidt wrote:
It seems I was wrong. I've manually applied the patch at the wrong
place. After patching the correct function
I'm not getting hard resets any more, which is a great improvement !
Thanks a lot, I really appreciate your help !
This is somewhat funny...
On Tue, 2010-01-12 at 00:48 +0200, Felix Radensky wrote:
>
> Maybe because the bus behind root P2P bridge is bus 0, and type 1
> cycles are
> needed for bus numbers greater than 0. That's what 460EX manual says.
Well, no... the bus behind the root P2P is bus 1 ... the root P2P itself
is on bus 0.
On Sat, Jan 9, 2010 at 4:01 AM, Alexey Dobriyan wrote:
> On Thu, Jan 07, 2010 at 01:19:13PM +1100, Jeremy Kerr wrote:
>> Commit e22f628395432b967f2f505858c64450f7835365 introduced a build
>> breakage for ARM devtree work: the THIS_MODULE macro was added, but we
>> don't have module.h
>>
>> This ch
Hi all,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
cc1: error: include/linux/autoconf.h: No such file or directory
(while building the boot wrappers - lots more of the same)
Caused by commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 ("zlib:
optimize inffast when copying
Stephen Rothwell wrote on 12/01/2010 00:58:05:
>
> Hi all,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> cc1: error: include/linux/autoconf.h: No such file or directory
>
> (while building the boot wrappers - lots more of the same)
>
> Caused by commit ac4c2a3bbe5db5
On Tue, 2009-12-22 at 20:04 +0530, Amit Shah wrote:
> From: Rusty Russell
>
> This is nicer for modern R/O protection. And noone needs it non-const, so
> constify the callers as well.
Rusty, do you want me to take these via powerpc ?
Cheers,
Ben.
> Signed-off-by: Rusty Russell
> Signed-off-b
> The intention of the cpu_hotplug_driver_locks to add additional serialization
> during cpu hotplug operations. For pseries this is used during DLPAR of cpu
> operations so that cpu hotplug actions cannot be initiated whiloe a DLPAR
> operation is in flight. For example, during DLPAR add we tak
commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 (zlib: optimize inffast when
copying direct from output) referenced include/linux/autoconf.h which
is now called include/generated/autoconf.h.
Signed-off-by: Anton Blanchard
---
Index: linux-cpumask/arch/powerpc/boot/Makefile
=
Hi Anton !
For some reason I can't find that patch in my mailbox (just saw it on
patchwork :-)
Here's a quick review. Looks good but two things:
- Please make it swsusp_booke.c, 44x support is trivial and I don't
want to rename the file :-)
- Is there really an SDR1 register on FSL BookE ? It
On Fri, 2010-01-08 at 17:46 +0100, Joakim Tjernlund wrote:
> The newly added fixup for buggy dcbX insn's has
> a bug that always trigger a kernel TLB walk so a user space
> dcbX insn will cause a Kernel Machine Check if it hits DTLB error.
>
> Signed-off-by: Joakim Tjernlund
> ---
>
> I found th
Hi Anton,
On Tue, 12 Jan 2010 13:21:51 +1100 Anton Blanchard wrote:
>
> commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 (zlib: optimize inffast when
> copying direct from output) referenced include/linux/autoconf.h which
> is now called include/generated/autoconf.h.
Even with this fix, you canno
Since most platforms will need a fixed-rate clock, add one. This will
also serve as a basic example of an implementation of struct clk.
Signed-off-by: Jeremy Kerr
---
include/linux/clk.h | 12
kernel/Makefile |1 +
kernel/clk.c| 25 +
3 f
icst307_ps_to_vco isn't used, so remove it.
Signed-off-by: Jeremy Kerr
---
arch/arm/common/icst307.c | 62 --
1 file changed, 62 deletions(-)
diff --git a/arch/arm/common/icst307.c b/arch/arm/common/icst307.c
index cd45b88..9d8d087 100644
--- a/arch/arm/co
We only use one value for oscoff, so remove it from the struct.
Signed-off-by: Jeremy Kerr
---
arch/arm/mach-versatile/clock.h |1 -
arch/arm/mach-versatile/core.c |6 +++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-versatile/clock.h b/arch/arm/mach-
Both the realview and versatile platforms use an icst307 clock, but have
their own clock structures.
This change introduces a struct icst307_clk, which is common between
realview and versatile. This allows us to take out the platform-specific
clock defintions.
Tested on versatile, compiled only o
Use the common struct clk interface for the realview clocks.
Compile tested only.
Signed-off-by: Jeremy Kerr
---
arch/arm/Kconfig |1
arch/arm/mach-realview/clock.c | 48 +
arch/arm/mach-realview/clock.h | 17 ++-
arch/arm/mach-rea
Use the common struct clk interface for the versatile clocks.
Signed-off-by: Jeremy Kerr
---
arch/arm/Kconfig|1
arch/arm/common/clkdev.c|2 +
arch/arm/mach-versatile/clock.c | 51 +---
arch/arm/mach-versatile/clock.h | 20 +++
We currently have 21 definitions of struct clk in the ARM architecture,
each defined on a per-platform basis. This makes it difficult to define
platform- (or architecture-) independent clock sources without making
assumptions about struct clk.
This change is an effort to unify struct clk where pos
Hi all,
These patches are an attempt to allow platforms to share clock code. At
present, the definitions of struct clk are local to platform code, which
makes allocating and initialising cross-platform clock sources
difficult.
The first two patches are for the architecture-independent kernel code
Benjamin Herrenschmidt wrote on 12/01/2010 03:40:45:
>
> On Fri, 2010-01-08 at 17:46 +0100, Joakim Tjernlund wrote:
> > The newly added fixup for buggy dcbX insn's has
> > a bug that always trigger a kernel TLB walk so a user space
> > dcbX insn will cause a Kernel Machine Check if it hits DTLB er
Hello Grant,
On Monday 11 January 2010 20:15:58 Grant Likely wrote:
> No patch description? Very few patches are sufficiently described by
> the subject line alone. Tell me what the problem is, what the patch
> changes, and why.
And a lot of other information. Thank you very much for the effor
Anton Blanchard wrote on 12/01/2010 03:21:51:
>
>
> commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 (zlib: optimize inffast when
> copying direct from output) referenced include/linux/autoconf.h which
> is now called include/generated/autoconf.h.
>
> Signed-off-by: Anton Blanchard
> ---
>
> Index
Hello Grant,
On Monday 11 January 2010 21:19:14 Grant Likely wrote:
> I'm really not convinced.
At least you made me think about that some more. And of course, you
are right, the order must be fixed, one way using TX, the other way
using RX.
I think delayed BCOM IRQs in TX direction, caused by
Hello Grant,
On Monday 11 January 2010 20:21:22 Grant Likely wrote:
> Unrelated whitespace change?
My fault, as with some other white space changes. My Emacs is
configured using some older setup found in a 2.4
Documentation/CodingStyle. Before saving a file my spine is used to
reformat the whole
60 matches
Mail list logo
