The following commits have been added to powerpc next:
Anton Vorontsov (1):
powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers
Arnd Bergmann (1):
powerpc/spufs: Initialize ctx-stats.tstamp correctly
Benjamin Herrenschmidt (1):
powerpc: Wire up
The following commits have been added to powerpc test:
Andrew Klossner (1):
powerpc/udbg: Fix lost byte during console handover; change LFCR
to CRLF
Benjamin Herrenschmidt (10):
powerpc/mm: Properly wire up get_user_pages_fast() on 32-bit
powerpc/kconfig: Kill PPC_MULTIPLATFORM
Tejun Heo wrote:
Impact: remove spurious WARN on legacy SMP percpu allocator
Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
allocator. Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
for UP but
On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote:
On Wed, 2009-03-11 at 00:45 +, Thomas Gleixner wrote:
plain text document attachment
(powerpc-convert-obsolete-irq-desc-t-typedef.patch)
Impact: cleanup
Convert the last remaining users.
Ack. This would be more easily carried
Benjamin Herrenschmidt wrote:
The problem is that the controller is hardwired to use only one
chipselect, even if both are enabled in the DDR0_10 on PPC440EPx/GRx
processors
Mikhail, can you verify that Valentine's patch works for you ?
Ben, unfortunately on my board(s) I don't have both
Valentine wrote:
The problem is that the controller is hardwired to use only one
chipselect, even if both are enabled in the DDR0_10 on PPC440EPx/GRx
processors.
It's new information for me. Is this problem described by some ERRATA or
manual, could you please point me to the document (and
FYI pseries_defconfig and ppc64_defconfig boot fine with this on BML
systemsim.
Mikey manual kisskb Neuling
The following commits have been added to powerpc test:
Andrew Klossner (1):
powerpc/udbg: Fix lost byte during console handover; change LFCR
to CRLF
Benjamin Herrenschmidt
In ehea_probe_adapter() the initial memory allocation and initialisation does
not need to be done with the ehea_fw_handles.lock semaphore held. Doing so
extends the amount of time the lock is held unnecessarily.
Signed-off-by: David Howells dhowe...@redhat.com
---
drivers/net/ehea/ehea_main.c
* Tejun Heo t...@kernel.org wrote:
Impact: remove spurious WARN on legacy SMP percpu allocator
Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
allocator. Commit e317603694bfd17b28a40de9d65e1a4ec12f816e
On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote:
Here are some late fixes for 2.6.29. I've included a radeonfb/aty128fb commit
Will you also take care of the new ps3vram driver, which has been ack'ed by
Jens for 2.6.29?
Or do you prefer it to go in by email through Geoff (as PS3 maintainer),
Hi David,
thanks for your patch. Coincidentally we have been working on a patch that
does some locking rework and also touches this particular lock.
So your patch finnally won't be required anymore. Thanks anyway for trying
to improve the eHEA driver!
I'm going to post our patch later today.
Benjamin Herrenschmidt wrote:
On Wed, 2009-03-11 at 01:39 +0200, Felix Radensky wrote:
Benjamin Herrenschmidt wrote:
On Wed, 2009-03-11 at 00:14 +0200, Felix Radensky wrote:
Yes, seems logical. U-boot has code to enable and disable loopback clock
for 440SPE,
Hi all
I am newer to linux.
My board is MPC750+MPC106, and I use MAPB for MPC106.
Due to 106 datasheet,
0x8000, -- 0xFC00, for PCI memory space.
As you know, user space is 0~0xbfff, (3G).
0xc000, ~ 0x,(1G) is for kernel.
And my question is:
1)
Hi all
I am newer to linux.
My board is MPC750+MPC106, and I use MAPB for MPC106.
Due to 106 datasheet,
0x8000, -- 0xFC00, for PCI memory space.
As you know, user space is 0~0xbfff, (3G).
0xc000, ~ 0x,(1G) is for kernel.
And my question is:
1) where should I
Hi Kyle,
On Mon, 9 Mar 2009, Geert Uytterhoeven wrote:
These patches are relative to the rtc-parisc branch of Kyle's PA-RISC git
repository, which already contains some cleanups for the rtc-parisc driver by
Dann, which already have been ack'ed by Alessandro:
On Tue, Mar 10, 2009 at 10:50:13PM +0300, Valentine Barshak wrote:
I was just going to submit a patch for that too.
Indeed, the denali_fixup_memsize() miscalculated a couple of address
field widths. We were lucky to eventually get the right result,
because the effect of the first error was killed
On Wed, 2009-03-11 at 10:37 +0100, Geert Uytterhoeven wrote:
On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote:
Here are some late fixes for 2.6.29. I've included a radeonfb/aty128fb
commit
Will you also take care of the new ps3vram driver, which has been ack'ed by
Jens for 2.6.29?
Or
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
In the last pull I think you might have had a tree of mine before these
few minor commits.
arch/powerpc/Makefile |4 ++--
Use device tree to determine if we actually have an MPIC and use
CPU feature to decide if we should use doorbells for IPIs.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/platforms/85xx/smp.c | 43 ++---
1 files changed, 35 insertions(+), 8
CoreInt provides a mechansim to deliver the IRQ vector directly
into the core on an interrupt (via the SPR EPR) rather than having
to go IACK on the PIC. This is suppose to provide an improvment
in interrupt latency by reducing the time to get the IRQ vector.
Signed-off-by: Kumar Gala
On Mar 10, 2009, at 10:53 PM, Benjamin Herrenschmidt wrote:
config PPC_NATIVE
bool
- depends on PPC_MULTIPLATFORM
+ depends on 6xx || PPC64
help
Support for running natively on the hardware, i.e. without
a hypervisor. This option is not
Hi all,
I'm trying to send some data through DMA from a memory buffer to a PCI
video card VRAM.
While I got that I need to alloc the src buffer through
dma_alloc_coherent, I don't understand which address I should give as
the dst address.
I tried both the mapped hw address and an address
I have upgraded to the latest John Linn's stable PPC kernel (2.6.25rc9)
and I have applied the patch v11(latest) from Peter Korsgaard for the
c67x00. I get the same problem with that, plus an added feature of my
Xilinx Temac driver not working anymore :/
loaded at: 0040
0056B19C
Benjamin Herrenschmidt wrote:
On Thu, 2009-03-05 at 13:53 -0600, Nathan Fontenot wrote:
The return code from invoking the notifier chain when updating the
ibm,dynamic-memory property is not handled properly. In failure
cases (rc == NOTIFY_BAD) we should be restoring the original value
of the
CoreInt provides a mechansim to deliver the IRQ vector directly
into the core on an interrupt (via the SPR EPR) rather than having
to go IACK on the PIC. This is suppose to provide an improvment
in interrupt latency by reducing the time to get the IRQ vector.
Signed-off-by: Kumar Gala
Hi,
This is a follow-up on NFS problems on an MPC5200-based board reported
here a while back:
http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-to21750004.html#a21792612
To recap: while using NFS, especially while mounting the root
filesystem over NFS, the system is
Has anyone been able to get a newer Freescale BSP to work with a RevA
(processor version 1.0) RDB?
The boards we received didn't have SPI compiled into the kernel and
when we went to go re-compile the kernel using the 20081222 and
20080711 BSPs. I realize that the interrupts were reversed
On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote:
I'd like to have Andrew or Linus opinion on doing this driver swap that
late in the process.
Quite franklly, no.
If it was a totally _new_ driver, there's no chance of regression, which
is why we allow those drivers.
But switching an
On Mar 11, 2009, at 10:52 AM, Mark Bishop wrote:
Has anyone been able to get a newer Freescale BSP to work with a
RevA (processor version 1.0) RDB?
The boards we received didn't have SPI compiled into the kernel and
when we went to go re-compile the kernel using the 20081222 and
On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote:
Is it OK for you to take it through your PA-RISC tree?
If yes, I can resend the patch series with the collected acks.
That's fine with me, just hit me up with a git tree address and I'll
suck it all into the rtc-parisc tree?
Yes I have actually. I have booted a 2.6.28.6. Same problem.
Also, is it me but at some point from 2.6.23 to 2.6.28 did they
started using hex numbers in the .dts file for interrupts = without
the 0x preamble?
I've been looking at 2.6.20, 2.6.23, and 2.6.28 .dts files for this
board
A semicolon at the end of the macro means that the for loop has an
empty body, and so TSEC/MDIO will not work with older device trees.
This fix only applies to 2.6.28; apparently, this code is gone for
2.6.29, according to Grant Likely!
Signed-off-by: Johns Daniel johns.dan...@gmail.com
---
---
On Wed, Mar 11, 2009 at 06:46:03AM -0500, Kumar Gala wrote:
+void __init mpc85xx_smp_init(void)
+{
+ struct device_node *np;
+
+ smp_85xx_ops.message_pass = NULL;
+
+ np = of_find_node_by_type(NULL, open-pic);
We should probably look by compatible rather than device_type. I
Hi Linus,
On Wed, 11 Mar 2009, Linus Torvalds wrote:
On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote:
I'd like to have Andrew or Linus opinion on doing this driver swap that
late in the process.
Quite franklly, no.
If it was a totally _new_ driver, there's no chance of
Hi there,
I've been examining the fsl dma driver (drivers/dma/fsldma.c) to work
out how a typical dma engine driver works so I can port an Intel dma
engine driver to the new dmaengine interface.
I have noticed that append_ld_queue() changes the next link descriptor
address field in the last
On Wed, Mar 11, 2009 at 9:50 AM, Johns Daniel johns.dan...@gmail.com wrote:
A semicolon at the end of the macro means that the for loop has an
empty body, and so TSEC/MDIO will not work with older device trees.
This fix only applies to 2.6.28; apparently, this code is gone for
2.6.29,
On Wed, Mar 11, 2009 at 10:03:22AM -0600, Grant Likely wrote:
On Wed, Mar 11, 2009 at 9:50 AM, Johns Daniel johns.dan...@gmail.com wrote:
A semicolon at the end of the macro means that the for loop has an
empty body, and so TSEC/MDIO will not work with older device trees.
This fix only
Hey Ben, here's another -next pull request. I think this exhausts
everything in my queue. I'm sure someone will tell me if I've missed
anything. I'll update patchwork later today.
One commit is outside of arch/powerpc, but it is a xilinx-only change
to an SPI driver, and David has acked it.
On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
bus_register_notifier_alldev() is a variation on bus_register_notifier()
which also triggers the notifier callback for devices already on the bus
and already bound to drivers.
This
On Wed, Mar 11, 2009 at 12:09 AM, Roland Dreier rdre...@cisco.com wrote:
Are there really cases where spinning for 1 jiffy is too long of a
timeout?
If the result is a timeout, then I say no. A timeout is an error
condition, and the code will usually terminate.
It might make sense for the
On Wed, Mar 11, 2009 at 10:26 AM, Greg KH gre...@suse.de wrote:
On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
bus_register_notifier_alldev() is a variation on bus_register_notifier()
which also triggers the notifier callback for
Timur Tabi wrote:
On Wed, Mar 11, 2009 at 12:09 AM, Roland Dreier rdre...@cisco.com wrote:
Are there really cases where spinning for 1 jiffy is too long of a
timeout?
If the result is a timeout, then I say no. A timeout is an error
condition, and the code will usually terminate.
[snip]
On Wed, Mar 11, 2009 at 12:03:00PM -0400, Mark Bishop wrote:
Yes I have actually. I have booted a 2.6.28.6. Same problem.
I've booted many recent kernels on revA 8313ERDB; networking works fine.
I'll try 2.6.28.6 specifically, though u-boot is acting up at the moment
so I have to address that
On Wed, Mar 11, 2009 at 10:35:29AM -0600, Grant Likely wrote:
On Wed, Mar 11, 2009 at 10:26 AM, Greg KH gre...@suse.de wrote:
On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
bus_register_notifier_alldev() is a variation on
On Tue, Mar 10, 2009 at 6:24 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2009-03-10 at 19:22 -0500, Timur Tabi wrote:
Alan did have one valid point though. Determining how long to loop
for is architecture-specific. Using jiffies is bad, because even one
jiffy is too
Hi Kyle,
On Wed, 11 Mar 2009, Kyle McMartin wrote:
On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote:
Is it OK for you to take it through your PA-RISC tree?
If yes, I can resend the patch series with the collected acks.
That's fine with me, just hit me up with a
On Mar 11, 2009, at 10:52 AM, Scott Wood wrote:
On Wed, Mar 11, 2009 at 06:46:03AM -0500, Kumar Gala wrote:
+void __init mpc85xx_smp_init(void)
+{
+ struct device_node *np;
+
+ smp_85xx_ops.message_pass = NULL;
+
+ np = of_find_node_by_type(NULL, open-pic);
We should
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -22,6 +22,7 @@
#define MPIC_GREG_FEATURE_10x00010
#define MPIC_GREG_GLOBAL_CONF_00x00020
#defineMPIC_GREG_GCONF_RESET 0x8000
+#define
Quoting Scott Wood scottw...@freescale.com:
On Wed, Mar 11, 2009 at 12:03:00PM -0400, Mark Bishop wrote:
Yes I have actually. I have booted a 2.6.28.6. Same problem.
I've booted many recent kernels on revA 8313ERDB; networking works fine.
I'll try 2.6.28.6 specifically, though u-boot is
Josh Boyer wrote:
On Tue, Mar 10, 2009 at 10:50:13PM +0300, Valentine Barshak wrote:
I was just going to submit a patch for that too.
Indeed, the denali_fixup_memsize() miscalculated a couple of address
field widths. We were lucky to eventually get the right result,
because the effect of the
On Wed, Mar 11, 2009 at 11:51 AM, Scott Wood scottw...@freescale.com wrote:
One jiffy is fine, but two is just too long?
Any number of jiffies is *not* too long if a timeout occurs. However,
I think even one jiffy is too long if that's the normal condition.
Unfortunately, the driver may not
On Wed, 11 Mar 2009, Geert Uytterhoeven wrote:
Are you aware the old one was introduced in 2.6.29-rc1? So there cannot be a
regression from 2.6.28 or older.
Ahh, no, that part hadn't registered.
In that case, I guess I don't really care, as long as everybody involved
feels it's clearly
Timur Tabi wrote:
On Wed, Mar 11, 2009 at 11:51 AM, Scott Wood scottw...@freescale.com wrote:
One jiffy is fine, but two is just too long?
Any number of jiffies is *not* too long if a timeout occurs. However,
I think even one jiffy is too long if that's the normal condition.
I was under
On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood scottw...@freescale.com wrote:
I was under the impression that we were only talking about timeouts, and
that the common case was significantly shorter than that.
I think one of the concerns that Alan Cox raised is that the existence
of this macro
Timur Tabi wrote:
On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood scottw...@freescale.com wrote:
I was under the impression that we were only talking about timeouts, and
that the common case was significantly shorter than that.
I think one of the concerns that Alan Cox raised is that the
Scott Wood wrote:
Or you can say that atomic context is outside the scope of this macro.
No, I don't want to say that. We have wait_event_timeout() for larger-scale
operations. I'm just looking for something that can replace while (!condition);
--
Timur Tabi
Linux Kernel Developer @
Timur Tabi wrote:
Scott Wood wrote:
Or you can say that atomic context is outside the scope of this macro.
No, I don't want to say that. We have wait_event_timeout() for
larger-scale operations. I'm just looking for something that can
replace while (!condition);
wait_event_timeout()
On Wed, Mar 11, 2009 at 10:52 AM, Crossley, Malcolm (GE EntSol,
Intelligent Platforms) malcolm.crossl...@gefanuc.com wrote:
I have noticed that append_ld_queue() changes the next link descriptor
address field in the last link descriptor of the chain. The
append_ld_queue function is called from
On Wed, 2009-03-11 at 07:04 -0500, Kumar Gala wrote:
On Mar 10, 2009, at 10:53 PM, Benjamin Herrenschmidt wrote:
config PPC_NATIVE
bool
- depends on PPC_MULTIPLATFORM
+ depends on 6xx || PPC64
help
Support for running natively on the hardware, i.e. without
On Wed, 2009-03-11 at 16:08 +0100, Bartłomiej Sięka wrote:
Hi,
This is a follow-up on NFS problems on an MPC5200-based board reported
here a while back:
http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-to21750004.html#a21792612
To recap: while using NFS, especially
No, not udelay. Or any delay for that matter. If spinning on a
condition, then there is no advantage to burning cycles with a
udelay(). Those cycles may as well be used to keep testing the
condition so the loop can be exited faster. a udelay() would only
serve to always make the busywait
Benjamin Herrenschmidt wrote:
Well, there's a non-empty set of HW where polling as fast as you can
will effectively prevent it to make fwd progress...
Alan Cox mentioned this. He gave PCI and 10us as an example. I suggested
adding a third parameter that would be a udelay() inserted into
On Wed, Mar 11, 2009 at 10:06:11PM +0300, Valentine Barshak wrote:
Josh Boyer wrote:
On Tue, Mar 10, 2009 at 10:50:13PM +0300, Valentine Barshak wrote:
I was just going to submit a patch for that too.
Indeed, the denali_fixup_memsize() miscalculated a couple of address
field widths. We were
Josh Boyer wrote:
On Wed, Mar 11, 2009 at 10:06:11PM +0300, Valentine Barshak wrote:
Josh Boyer wrote:
On Tue, Mar 10, 2009 at 10:50:13PM +0300, Valentine Barshak wrote:
I was just going to submit a patch for that too.
Indeed, the denali_fixup_memsize() miscalculated a couple of address
field
Impact: performance improvement
This fixes 'powerpc: avoid cpumask games in arch/powerpc/kernel/sysfs.c'
which talked about using smp_call_function_single, but actually used
work_on_cpu (an older version of the patch).
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
Original-Nachricht
Datum: Thu, 12 Mar 2009 08:39:26 +1100
Von: Benjamin Herrenschmidt b...@kernel.crashing.org
An: Bartłomiej Sięka t...@semihalf.com
CC: linuxppc-dev@ozlabs.org, gerhard_pirc...@gmx.net, Grant Likely
grant.lik...@secretlab.ca
Betreff: Re: NFS problems on
Timur Tabi wrote:
Benjamin Herrenschmidt wrote:
Well, there's a non-empty set of HW where polling as fast as you can
will effectively prevent it to make fwd progress...
Alan Cox mentioned this. He gave PCI and 10us as an example. I
suggested adding a third parameter that would be a
On Thu, Mar 12, 2009 at 01:08:59AM +0300, Valentine wrote:
So, probably the best way would be to fix that in u-boot
amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x0100); instead
of mtsdram(DDR0_10, 0x0300);
Sorry, for confusion, but after reviewing the docs, I think that
only
Add the definition of the fsl,ssi-asynchronous property to ssi.txt
(documentation
of the device tree bindings for the Freescale SSI device).
Also tidy up the layout of ssi.txt.
Signed-off-by: Timur Tabi ti...@freescale.com
---
v3: rebased
v2: fixed typo, improved wording.
The page_ins member ends at byte 0x3, not 0x4. Also, fix up the
alignment.
Signed-off-by: Jeremy Kerr j...@ozlabs.org
---
arch/powerpc/include/asm/lppaca.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/lppaca.h
PAPR v2.3 defines fields in the virtual processor area for a dispatch
trace log (DLT). Since we'd like to use the DLT, add the necessary
fields to struct lppaca.
Signed-off-by: Jeremy Kerr j...@ozlabs.org
---
arch/powerpc/include/asm/lppaca.h |6 --
1 file changed, 4 insertions(+), 2
pseries SPLPAR machines are able to retrieve a log of dispatch and
preempt events from the hypervisor. With this information, we can
see when and why each dispatch preempt is occuring.
This change adds a set of debugfs files allowing userspace to read this
dispatch log.
Based on initial patches
We have a board similar to the MPC8323 rdb. In the board we have
connected the IDSEL to AD18 we have only one minipci connector for it. We
have interfaced a Wlan Card . When we do
# lspci -x we get following
00:12.0 Network controller: RaLink RT2561/RT61 802.11g PCI
00: 14 18 01 03 07 00 10
73 matches
Mail list logo
