Hi,
I am having some problem booting linux on Powerpc 405 (xilinx virtex4).
I have the following output on the terminal:
**
zImage starting: loaded at 0x0040 (sp: 0x0070feb0)
Allocating 0x38a79c bytes for kernel ...
gunzipping (0x000
On Wednesday 11 March 2009, Valentine Barshak wrote:
> I've been looking at the docs once again and actually I couldn't find an
>explanation there. And I don't have that e-mail from AMCC support
> that I got a while back regarding the issue anymore.
> There might have been some misunderstanding
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 0
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
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
---
arch/powerpc/include/asm/lppaca.h |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
The page_ins member ends at byte 0x3, not 0x4. Also, fix up the
alignment.
Signed-off-by: Jeremy Kerr
---
arch/powerpc/include/asm/lppaca.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/lppaca.h
b/arch/powerpc/include/asm/lppaca.h
index 25aaa97
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
---
v3: rebased
v2: fixed typo, improved wording.
Documentation/powerpc/dts-bindings/fsl
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
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 udelay(
Original-Nachricht
> Datum: Thu, 12 Mar 2009 08:39:26 +1100
> Von: Benjamin Herrenschmidt
> An: "Bartłomiej Sięka"
> CC: linuxppc-dev@ozlabs.org, gerhard_pirc...@gmx.net, Grant Likely
>
> Betreff: Re: NFS problems on a MPC5200-based board
> On Wed, 2009-03-11 at 16:08 +0100,
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
---
arch/powerpc/kernel/sysfs.c | 11 ++--
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
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
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 the
> 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 busy
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, espec
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.
On Wed, Mar 11, 2009 at 10:52 AM, Crossley, Malcolm (GE EntSol,
Intelligent Platforms) 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 the fsl_dma_tx_submit() whi
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()
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 @ Fre
Timur Tabi wrote:
On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood 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 would e
On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood 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 would encourage people to
Timur Tabi wrote:
On Wed, Mar 11, 2009 at 11:51 AM, Scott Wood 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 the impression that we we
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
On Wed, Mar 11, 2009 at 11:51 AM, Scott Wood 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 have any choice in some
c
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 fir
Quoting Scott Wood :
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
--- 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
+#defineMP
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 prob
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 wi
On Tue, Mar 10, 2009 at 6:24 PM, Benjamin Herrenschmidt
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 long. Adding a u
On Wed, Mar 11, 2009 at 10:35:29AM -0600, Grant Likely wrote:
> On Wed, Mar 11, 2009 at 10:26 AM, Greg KH wrote:
> > On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote:
> >> From: Grant Likely
> >>
> >> bus_register_notifier_alldev() is a variation on bus_register_notifier()
> >> which
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
Timur Tabi wrote:
On Wed, Mar 11, 2009 at 12:09 AM, Roland Dreier 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]
Two jiffies can be a
On Wed, Mar 11, 2009 at 10:26 AM, Greg KH wrote:
> On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote:
>> From: Grant Likely
>>
>> bus_register_notifier_alldev() is a variation on bus_register_notifier()
>> which also triggers the notifier callback for devices already on the bus
>> and
On Wed, Mar 11, 2009 at 12:09 AM, Roland Dreier 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 parameter passed
On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote:
> From: Grant Likely
>
> 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 function is useful f
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.
Ch
On Wed, Mar 11, 2009 at 10:03:22AM -0600, Grant Likely wrote:
> On Wed, Mar 11, 2009 at 9:50 AM, Johns Daniel 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.2
On Wed, Mar 11, 2009 at 9:50 AM, Johns Daniel 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, according to Grant Likely
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 link
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
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_typ
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
---
--- linux-2.6.28.7/arch/pow
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
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
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
20080711
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
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
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 really
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
---
* Fixe
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 pro
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
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 re
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 user-sele
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
---
arch/
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
---
arch/powerpc/platforms/85xx/smp.c | 43 ++---
1 files changed, 35 insertions(+), 8 deletions(-)
diff --git
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 ++--
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
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 kill
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:
>
> http://git.kernel.
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 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
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, 440EPX,440GRX,405
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.
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), o
* 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
> f
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
---
drivers/net/ehea/ehea_main.c | 13 ++---
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 Herrens
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 pag
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 bit
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 easi
72 matches
Mail list logo
