> > I am able to reproduce the error using 2.6.29.2-rt11. I was able to
> > mitigate the problem by raising the priority of the transmit irq.
> > However when running an NFS server on the pcm030 under high cpu load I
> > now get
> >
> > [ 132.477503] net eth0: FEC_IEVENT_RFIFO_ERROR
> > [ 132.8
Hi David,
Just to correct the statements : How the DBCR0 is initialized on
targets that don't use boot loaders ?
-Srikant
On Wed, May 20, 2009 at 11:30 AM, David Gibson
wrote:
> On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote:
>> Hi David,
>>
>> I am not sure how the IDM beh
On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote:
> Hi David,
>
> I am not sure how the IDM behaves on few of PPC440 targets which don't
> have boot loaders. I have a reference for your question:
>
> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.h
Ben,
Comments on the pmac case?
- k
On Apr 29, 2009, at 3:49 PM, Kumar Gala wrote:
Signed-off-by: Kumar Gala
---
Ben,
My question is if we think fake_pci_bus will always get a valid
hose().
The users of EARLY_PCI_OP are fsl/8xxx, 4xx, and pmac. I verified
that
fsl/8xxx & 4xx pass a v
Hi David,
I am not sure how the IDM behaves on few of PPC440 targets which don't
have boot loaders. I have a reference for your question:
http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html
Without this fix (given patch) I am facing problems with GDB, and
further ta
From: Benjamin Herrenschmidt
Date: Wed, 20 May 2009 13:01:30 +1000
> For example, some of the OF parsing bits may fail to convert memory
> addresses to IO addresses if the PCI host bridges have not been
> discovered yet, potentially causing issues with matching of resources
> between the early se
On Tue, 2009-05-19 at 12:05 -0700, David Miller wrote:
>
> This is also what sparc64 does :-)
>
> All of the individual sparc64 PCI controller types have a OF driver
> and then there is a common layer of OF PCI helper code to do most
> of the work.
I agree it's a good idea in the long run, but o
On Tue, 2009-05-19 at 21:17 -0600, Grant Likely wrote:
> On Tue, May 19, 2009 at 9:02 PM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2009-05-19 at 09:25 -0700, Stephen Neuendorffer wrote:
> >
> >> I agree that something is called for... The first might be slightly
> >> simpler, since it would pr
Hi,
Now I attempt to fetch data from peripheral device to SDRAM, and it has been
successed
but how the DMA controller know the data bandwidth of src and dest.
for example, if i get a 16bits data with a 32bits bus, and other 16bits will
be set high
and data will fetched into cache line of dma,
excuse me
I hate to bother everyone but I have a question about DMA of PCI bridge
Now I attempt to fetch data from peripheral device to SDRAM, and it has been
successed
but how the DMA controller know the data bandwidth of src and dest.
for example, if i get a 16bits data with a 32bits bus, and
On Tue, May 19, 2009 at 9:02 PM, Benjamin Herrenschmidt
wrote:
> On Tue, 2009-05-19 at 09:25 -0700, Stephen Neuendorffer wrote:
>
>> I agree that something is called for... The first might be slightly
>> simpler, since it would probably transparently deal with the presence
>> of more than one PLB
On Tue, 2009-05-19 at 09:25 -0700, Stephen Neuendorffer wrote:
> I agree that something is called for... The first might be slightly
> simpler, since it would probably transparently deal with the presence
> of more than one PLB->PCI bridge?
The current code doesn't already ?
Cheers,
Ben.
On Tue, 2009-05-19 at 09:28 -0600, Grant Likely wrote:
> 1) Probe the host controller in an of_platform driver. This has the
> advantage of simplicity. The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. The b
This patch fixes a couple of issues that can happen as a result
of steal_context() dropping the context_lock when all possible
PIDs are ineligible for stealing (hopefully an extremely hard to
hit occurence).
This case exposes the possibility of a stale context_mm[] entry
to be seen since destroy_c
Hi John,
Did you use DMA driver in our FEC driver before?
Best Regards,
Hongjun Chen
2009-05-20
发件人: Piotr Zięcik
发送时间: 2009-05-19 16:05:05
收件人: Hongjun Chen
抄送: Wolfgang Denk; linuxppc-dev@ozlabs.org
主题: Re: [PATCH 11/12] mpc5121: Added MPC512x DMA driver.
Tuesday 19 May 2009 03:37:47 Hon
Do not go beyond ARRAY_SIZE of tape_device and viotape_unitinfo
Signed-off-by: Roel Kluin
Acked-by: Stephen Rothwell
---
diff --git a/drivers/char/viotape.c b/drivers/char/viotape.c
index ffc9254..042c814 100644
--- a/drivers/char/viotape.c
+++ b/drivers/char/viotape.c
@@ -867,7 +867,7 @@ static
Do not go beyond ARRAY_SIZE of mpc52xx_uart_{ports,nodes}
Signed-off-by: Roel Kluin
---
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 7f72f8c..b3feb61 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -988,7 +988,7 @@ mpc52xx_cons
On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote:
> Hi,
>
> kernel- 2.6.29
> Debug technique: KGDB
>
> The PowerPC kernel does not initialize the PPC440 DBCR0 register. This
> prevents the use of software breakpoints in case of internal debug
> mode. Looking into head_fsl_booke
On Tue, May 19, 2009 at 4:21 PM, Eric Millbrandt
wrote:
> -Original Message-
> From: Wolfram Sang [mailto:w.s...@pengutronix.de]
> Sent: Tuesday, May 19, 2009 16:57
> To: Robert Schwebel
> Cc: Eric Millbrandt; linuxppc-dev@ozlabs.org
> Subject: Re: mpc5200 fec error
>
> On Tue, May 19, 200
When using the DMA controller from multiple threads at the same time, it is
possible to get lots of "DMA halt timeout!" errors printed to the kernel
log.
This occurs due to a race between fsl_dma_memcpy_issue_pending() and the
interrupt handler, fsl_dma_chan_do_interrupt(). Both call the
fsl_chan_
-Original Message-
From: Wolfram Sang [mailto:w.s...@pengutronix.de]
Sent: Tuesday, May 19, 2009 16:57
To: Robert Schwebel
Cc: Eric Millbrandt; linuxppc-dev@ozlabs.org
Subject: Re: mpc5200 fec error
On Tue, May 19, 2009 at 10:36:45PM +0200, Robert Schwebel wrote:
> Wolfram, have you seen
On Tue, 2009-05-19 at 13:26 +0200, Piotr Zięcik wrote:
> Tuesday 19 May 2009 00:17:31 Benjamin Herrenschmidt wrote:
> >
> > We are close to the point where we can make this a runtime option
> > though, by just having a different set of dma_ops hooked in.
> >
>
> Is somebody currently working on it
Grant Likely wrote:
> Hmmm, the ret value is backwards from what most coders would expect
> (zero on success, non-zero on failure). I'd personally recommend
> reversing the polarity in the macro.
The ret value is documented as being the value of the expression when the loop
terminates. The rea
On May 19, 2009, at 12:27 AM, FUJITA Tomonori wrote:
CC'ed linux-kernel
On Thu, 14 May 2009 17:42:28 -0500
Becky Bruce wrote:
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms. Probably the most inter
On Tue, May 19, 2009 at 10:36:45PM +0200, Robert Schwebel wrote:
> Wolfram, have you seen this mail? You recently tested -rt on 2.6.29,
> right? Did you only test that on the customer hardware or also on the
> phyCORE-MPC5200B?
So far, I tried only on customer hardware, and that was 2.6.29.2-rt11.
On Tue, May 19, 2009 at 2:30 PM, Wolfram Sang wrote:
>> This name is too generic for an of_platform device. 'mtd' needs to be
>> in there somewhere.
>
> Will "of-mtd-ram" do? (I'd think so)
fine by me.
g
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
_
Wolfram, have you seen this mail? You recently tested -rt on 2.6.29,
right? Did you only test that on the customer hardware or also on the
phyCORE-MPC5200B?
rsc
On Mon, May 18, 2009 at 01:36:27PM -0400, Eric Millbrandt wrote:
> Hello all,
>
>
>
> I am testing a 2.6.29.3 (with preempt_rt patch
Hi Grant,
thanks a lot for the review!
On Tue, May 19, 2009 at 08:57:15AM -0600, Grant Likely wrote:
> On Wed, Jan 21, 2009 at 11:41 AM, Wolfram Sang wrote:
> > Create an of-aware driver using the now exported generic functions from
> > plat-ram.c. A typical oftree snipplet for it looks like thi
On Tue, May 19, 2009 at 1:26 PM, Timur Tabi wrote:
> The qe_issue_cmd() function (Freescale PowerPC QUICC Engine library) polls on
> a register until a status bit changes, but does not include a timeout to
> handle the situation if the bit never changes. Change the code to use the new
> spin_even
On May 19, 2009, at 8:04 AM, Kumar Gala wrote:
On May 18, 2009, at 4:49 PM, Benjamin Herrenschmidt wrote:
On Mon, 2009-05-18 at 08:25 -0500, Kumar Gala wrote:
Part of this is how the generic swiotlb code works and part of it
was
our desire not to bloat dev archdata by adding such info that
On Tue, May 19, 2009 at 1:05 PM, David Miller wrote:
> From: Arnd Bergmann
> Date: Tue, 19 May 2009 18:12:02 +0200
>
>> On Tuesday 19 May 2009, Grant Likely wrote:
>>> 1) Probe the host controller in an of_platform driver. This has the
>>> advantage of simplicity. The probe routine will get aut
Introduce the spin_event_timeout() macro, and update the QE library to use it.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
The qe_issue_cmd() function (Freescale PowerPC QUICC Engine library) polls on
a register until a status bit changes, but does not include a timeout to
handle the situation if the bit never changes. Change the code to use the new
spin_event_timeout() macro, which simplifies polling on a register wi
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns the result of the condition when the loop
was terminated.
This primary purpose of this macro is to poll on a hardware
From: Arnd Bergmann
Date: Tue, 19 May 2009 18:12:02 +0200
> On Tuesday 19 May 2009, Grant Likely wrote:
>> 1) Probe the host controller in an of_platform driver. This has the
>> advantage of simplicity. The probe routine will get automatically
>> called when the PCI host controller device tree
Hi Wolfram!
Am 19.05.09 14:27 schrieb(en) Wolfram Sang:
I wrote such a driver (yet without partitioning support) and I am
trying to get it mainline, just didn't get any comments so far:
http://patchwork.ozlabs.org/patch/23557/
http://patchwork.ozlabs.org/patch/23556/
Thanks a lot, this is *
On Tue, May 19, 2009 at 10:25 AM, Stephen Neuendorffer
wrote:
>
>> 1) Probe the host controller in an of_platform driver. This has the
>> advantage of simplicity. The probe routine will get automatically
>> called when the PCI host controller device tree node is registered
>> with the of_platfor
> 1) Probe the host controller in an of_platform driver. This has the
> advantage of simplicity. The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. The bus parenthood also gets reflected in
> the device model
On Tuesday 19 May 2009, Grant Likely wrote:
> 1) Probe the host controller in an of_platform driver. This has the
> advantage of simplicity. The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. The bus parenthoo
Hey all,
I've been having some thoughts on PCI host controller probing and how
best to handle it. Currently AFAICT, the SoC platform code explicitly
calls the PCI setup code. In all of the existing SoCs this works fine
because there is SoC specific platform code which knows what PCI
busses to ex
On Wed, Jan 21, 2009 at 11:41 AM, Wolfram Sang wrote:
> Create an of-aware driver using the now exported generic functions from
> plat-ram.c. A typical oftree snipplet for it looks like this:
>
> s...@04e0 {
> compatible = "mtd-ram";
> reg = <0x04e0 0x0020>;
> bank
On Wed, Jan 21, 2009 at 11:41 AM, Wolfram Sang wrote:
> Refactor the probe and remove routines of the mtd-ram driver to export
> a generic part which can later be accessed by an of-counterpart of this
> driver. Tested with a phyCORE-MPC5200B-IO.
>
> Signed-off-by: Wolfram Sang
On brief review, l
On Tue, May 19, 2009 at 6:27 AM, Wolfram Sang wrote:
> Hello Albrecht,
>
> (adding linux-mtd)
>
> On Tue, May 19, 2009 at 01:59:00PM +0200, Albrecht Dreà wrote:
>>
>> is there a standard way to define a ram chip (in my case a battery-buffered
>> nv ram, attached to the 5200's Local Bus) in the OF
Hi,
kernel- 2.6.29
Debug technique: KGDB
The PowerPC kernel does not initialize the PPC440 DBCR0 register. This
prevents the use of software breakpoints in case of internal debug
mode. Looking into head_fsl_booke.S for initialization of DBCR0 is
used by boot-loaders.
It seems head_44x.S lacks thi
On May 18, 2009, at 4:49 PM, Benjamin Herrenschmidt wrote:
On Mon, 2009-05-18 at 08:25 -0500, Kumar Gala wrote:
Part of this is how the generic swiotlb code works and part of it
was
our desire not to bloat dev archdata by adding such info that as you
say is either bus specific or conveyed in
On Mon, May 18, 2009 at 9:57 PM, Sean MacLennan wrote:
> On Mon, 18 May 2009 20:58:03 -0600
> Grant Likely wrote:
>
>> Then let it lie fallow on the list and in patchwork. It is published,
>> and people know that it is available (I'll certainly consider it as I
>> do driver work), but there must
Hello Albrecht,
(adding linux-mtd)
On Tue, May 19, 2009 at 01:59:00PM +0200, Albrecht Dreà wrote:
>
> is there a standard way to define a ram chip (in my case a battery-buffered
> nv ram, attached to the 5200's Local Bus) in the OF tree, and are there any
> drivers (on 2.6.29.1) which pick up t
Hi all,
is there a standard way to define a ram chip (in my case a battery-buffered nv
ram, attached to the 5200's Local Bus) in the OF tree, and are there any
drivers (on 2.6.29.1) which pick up the chip/partition specification for mtd?
Does such a driver exist, or do I have to write one (pro
Tuesday 19 May 2009 00:17:31 Benjamin Herrenschmidt wrote:
>
> We are close to the point where we can make this a runtime option
> though, by just having a different set of dma_ops hooked in.
>
Is somebody currently working on it? If yes, where we can see
code ?
--
Best Regards.
Piotr Zięcik
___
Mappings for temperature sensors (adt7461 and lm92) are missing from the
SBC610's DTS file.
Signed-off-by: Martyn Welch
---
arch/powerpc/boot/dts/gef_sbc610.dts | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts
b/arch/powerp
Piotr Zięcik wrote:
> Monday 18 May 2009 16:29:04 Wolfgang Grandegger napisał(a):
>>> I have simple question about bus speed setting support. Existing
>>> implementation uses default safe speed if there is no 'clock-frequency'
>>> property in i2c node. Comments in code suggest that this behaviour i
Tuesday 19 May 2009 03:37:47 Hongjun Chen wrote:
> Since you have reuse most part of our BSP, why should you reinvent wheel
> for MPC512x DMA? We have one ready DMA driver, which has been used by AC97,
> ATA, VIU etc.
>
Answer is simple. The old one does not fit Linux DMA API. New one uses
existi
Monday 18 May 2009 16:29:04 Wolfgang Grandegger napisał(a):
> > I have simple question about bus speed setting support. Existing
> > implementation uses default safe speed if there is no 'clock-frequency'
> > property in i2c node. Comments in code suggest that this behaviour is
> > left for backwar
On May 18, 2009, at 4:50 PM, Benjamin Herrenschmidt wrote:
On Mon, 2009-05-18 at 12:20 -0500, Scott Wood wrote:
I'm pretty sure the driver changes to address this are in dave's
net-
next tree.
Won't this break git bisect?
Not to mention anyone trying to use your tree now...
Right, thoug
54 matches
Mail list logo