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
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
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 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
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
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
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
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 +++
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
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
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-
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
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
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
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 !
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
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
=
> 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
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
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
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
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
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.
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 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?
> 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
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
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
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
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: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: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
>
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: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
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 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: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 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
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: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
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
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
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
==
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
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
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/
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
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
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
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 |
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
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
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
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,
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
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
==
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_
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.
[...]
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 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
60 matches
Mail list logo
