On Thu, 2009-06-25 at 14:27 +0800, Johnny Hung wrote:
> 2009/6/25 Benjamin Herrenschmidt :
> >
> >> Before the console is set up, the printk data is formatted
> >> and put into the kernel log buffer, but not sent to any console.
> >> Any messages printk'ed before that are buffered but do not
> >> a
2009/6/25 Benjamin Herrenschmidt :
>
>> Before the console is set up, the printk data is formatted
>> and put into the kernel log buffer, but not sent to any console.
>> Any messages printk'ed before that are buffered but do not
>> appear. When the console is initialized, then all buffered
>> mess
Anton Vorontsov wrote:
Currently the half-duplex operation seems to not work reliably for
RGMII/GMII PHY interfaces. It takes about 10 minutes to boot NFS
rootfs using 10/half link, following symptoms were observed:
ucc_geth: QE UCC Gigabit Ethernet Controller
ucc_geth: UCC1 at 0xe0082000 (i
Create the dts files for each core and splits the devices between
the two cores for P2020DS.
Resource partitioning follows the example set by MPC8572, with a
shared MIPC using protected resources, and with the remaining
resources divided as follows:
core0: memory, L2, i2c, dma1, global-util, eth0
Based on Kumar's new compatible types patch, add P2020 into
MPC85xx EDAC compatible lists so that EDAC can recognize
P2020 meomry controller and L2 cache controller and export
the relevant fields to sysfs.
EDAC MPC85xx DDR3 support is needed if DDR3 memory stick is
installed on a P2020DS board so
It appears that gianfar driver has the same problem with RGMII
half-duplex mode as ucc_geth.
NFS boot using 10/half link takes about 10 minutes to complete:
eth0: Gianfar Ethernet Controller Version 1.2, 00:11:22:33:44:55
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
[.
Currently the half-duplex operation seems to not work reliably for
RGMII PHY interfaces. It takes about 10 minutes to boot NFS rootfs
using 10/half link, following symptoms were observed:
ucc_geth: QE UCC Gigabit Ethernet Controller
ucc_geth: UCC1 at 0xe0082000 (irq = 32)
[...]
Sending DHC
> Before the console is set up, the printk data is formatted
> and put into the kernel log buffer, but not sent to any console.
> Any messages printk'ed before that are buffered but do not
> appear. When the console is initialized, then all buffered
> messages are sent to the console, and subsequ
kernel mailz wrote:
But If the app was running with PID=1, interrupt occurs, kernel code
gets executed in PID=1, how does the kernel handle this ? and goes
back to PID=0, since its translations are all in PID=0
PID 0 is special, it's mappings are present regardless of the value of
the PID regi
*Technically*, full
duplex is required for GMII, as GMII is used only for gigabit.
However,
we've been treating the GMII interface type as an indicator that
the PHY
*has* a GMII connection to the NIC. When gianfar detects the speed
is
10/100 it switches to the compatible MII interface vi
On Wed, Jun 24, 2009 at 6:45 PM, Kumar Gala wrote:
>
> On Jun 24, 2009, at 4:44 AM, kernel mailz wrote:
>
>> Hi,
>>
>> I am a newbie, trying to learn but have a few queries, nice if you could
>> respond
>> For linux on 85xx systems...
>>
>> (a) Kernel code runs in PR=0 AS=0 and PID=0, which user sp
On Thu, Jun 25, 2009 at 01:39:45AM +0400, Anton Vorontsov wrote:
> On Wed, Jun 24, 2009 at 04:25:06PM -0500, Andy Fleming wrote:
> [...]
> >>> My concern is that you will be detecting the GMII interface, and
> >>> disallowing half-duplex, despite the fact that the interface is
> >>> actually
> >>
On Wed, Jun 24, 2009 at 04:25:06PM -0500, Andy Fleming wrote:
[...]
>>> My concern is that you will be detecting the GMII interface, and
>>> disallowing half-duplex, despite the fact that the interface is
>>> actually
>>> running at 10 or 100 Mbit.
>>
>> Very interesting, though I'm not sure I'm
On Wed, Jun 24, 2009 at 03:18:59PM -0500, Andy Fleming wrote:
>
> On Jun 24, 2009, at 1:27 PM, Anton Vorontsov wrote:
>
>> It appears that gianfar driver has the same problem[1] that I
>> just fixed for ucc_geth.
>>
>> NFS boot using 10/half link takes about 10 minutes to complete:
>>
>
>>
>> The s
Kumar Gala wrote:
On Jun 24, 2009, at 12:56 PM, Dan Williams wrote:
Lets go ahead w/2.6.31 (if its ok w/you).
Ok, I'll take this as an acked-by and send it off.
Thanks,
Dan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.o
On Jun 24, 2009, at 1:27 PM, Anton Vorontsov wrote:
It appears that gianfar driver has the same problem[1] that I
just fixed for ucc_geth.
NFS boot using 10/half link takes about 10 minutes to complete:
The symptoms were observed on MPC8379E-RDB boards (eTSEC). Although
I didn't find wher
On Jun 24, 2009, at 12:56 PM, Dan Williams wrote:
Dan Williams wrote:
Kumar Gala wrote:
Kumar, Leo,
Can I get your acked-by's for the current state of async_tx.git/
next? I
just pushed out Ira's latest so it may take a moment to mirror
out.
Acked-by: Li Yang
However, the addition of
It appears that gianfar driver has the same problem[1] that I
just fixed for ucc_geth.
NFS boot using 10/half link takes about 10 minutes to complete:
eth0: Gianfar Ethernet Controller Version 1.2, 00:11:22:33:44:55
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
[...]
Dan Williams wrote:
Kumar Gala wrote:
Kumar, Leo,
Can I get your acked-by's for the current state of async_tx.git/
next? I
just pushed out Ira's latest so it may take a moment to mirror out.
Acked-by: Li Yang
However, the addition of arch/powerpc/include/asm/fsldma.h still needs
the ack f
Currently the half-duplex operation seems to not work reliably for
RGMII/GMII PHY interfaces. It takes about 10 minutes to boot NFS
rootfs using 10/half link, following symptoms were observed:
ucc_geth: QE UCC Gigabit Ethernet Controller
ucc_geth: UCC1 at 0xe0082000 (irq = 32)
[...]
Sendin
The code needs testing on other powerpc platforms.
I think given the numbers you showed this is a good improvement, and it
clearly can't do any harm on platforms that implement msleep correctly.
For what it's worth:
Acked-by: Joel Schopp
Signed-off-by: Gautham R Shenoy
---
arch/powerpc/
Linux isn't able to detect link changes on ethernet ports that were
used by U-Boot. This is because U-Boot wrongly clears interrupt
polarity bit (INTPOL, 0x400) in the extended status register (EXT_SR,
0x1b) of Marvell PHYs.
There is no easy way for PHY drivers to know IRQ line polarity (we
could
David Brownell wrote:
> On Wednesday 24 June 2009, Steven A. Falco wrote:
>> Your changes to bitbang_work look good.
>
> You tested?
>
Yes - I built a kernel with your patch, combined with the changes I
just posted to linuxppc-...@ozlabs.org as:
"[PATCH v1] Make spi_ppc4xx.c tolerate 0 bits-per
On Wednesday 24 June 2009, Steven A. Falco wrote:
> Your changes to bitbang_work look good.
You tested?
> I'm not clear on why you first set do_setup = -1 but later
> use do_setup = 1. Perhaps they should both be "1". Other than that,
>
> Acked-by: Steven A. Falco
The "-1" is for the init
On Wednesday 24 June 2009 16:36:58 Steven A. Falco wrote:
> > I have to admit that I didn't find the time to rework the driver after
> > David's latest review. Frankly, this could take some time since I'm
> > currently busy with other tasks. So it would be great if someone else
> > (Steven?) might
Stefan Roese wrote:
> On Wednesday 24 June 2009 16:25:20 Steven A. Falco wrote:
>>> Speaking of spi_ppc4xx issues ... I still have an oldish
>>> copy in my review queue, it needs something like the
>>> appended patch. (Plus something to accept bpw == 0.)
>>> Is there a newer version?
>> That is a
If a SPI transfer is set up, but does not explicitly set bits-per-word
and speed_hz, then the transaction fails, because spi_ppc4xx_setupxfer
rejects it.
This patch modifies the logic to chose the struct spi_transfer parameters
only if they are non-zero. Otherwise, the struct spi_device parameter
On Wednesday 24 June 2009 16:25:20 Steven A. Falco wrote:
> > Speaking of spi_ppc4xx issues ... I still have an oldish
> > copy in my review queue, it needs something like the
> > appended patch. (Plus something to accept bpw == 0.)
> > Is there a newer version?
>
> That is a question for Stefan.
David Brownell wrote:
> On Tuesday 23 June 2009, Steven A. Falco wrote:
>> m25p80 spi0.0: invalid bits-per-word (0)
>>
>> This message comes from spi_ppc4xx_setupxfer. I believe your patch
>> is doing what you intended (i.e. forcing an initial call to
>> spi_ppc4xx_setupxfer), but it exposes an OF
On Jun 24, 2009, at 4:44 AM, kernel mailz wrote:
Hi,
I am a newbie, trying to learn but have a few queries, nice if you
could respond
For linux on 85xx systems...
(a) Kernel code runs in PR=0 AS=0 and PID=0, which user space
application run in PR=1 AS=0 and PID 1-255.
Is this correct.
Add the missing ndo_set_mac_address function to enable changing MAC
address. Also remove the unnecessary gfar_set_mac_address function.
Signed-off-by: Li Yang
Acked-by: Andy Fleming
---
drivers/net/gianfar.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --gi
Time time taken for a single cpu online operation on a pseries machine
is as follows:
Dedicated LPAR (POWER6): ~220ms.
Shared LPAR (POWER5) : ~240ms.
Of this time, approximately 200ms is taken up by __cpu_up(). This is because
we poll every 200ms to check if the new cpu has notified it's presenc
Hi,
I am a newbie, trying to learn but have a few queries, nice if you could
respond
For linux on 85xx systems...
(a) Kernel code runs in PR=0 AS=0 and PID=0, which user space application
run in PR=1 AS=0 and PID 1-255.
Is this correct.
(b) I am writing a small program where the application code
At Wed, 24 Jun 2009 10:46:01 +0200,
Gerhard Pircher wrote:
>
>
> Original-Nachricht
> > Datum: Tue, 23 Jun 2009 23:42:24 +0200
> > Von: "Gerhard Pircher"
> > An: b...@kernel.crashing.org, ti...@suse.de
> > CC: linuxppc-...@ozlabs.org
> > Betreff: Re: ALSA fixes for non-coherent
On Wed, 2009-06-24 at 16:19 +1000, Michael Ellerman wrote:
> sym53c8xx :00:0c.0: enabling device (0140 -> 0143)
> sym0: <896> rev 0x7 at pci :00:0c.0 irq 17
> sym0: No NVRAM, ID 7, Fast-40, SE, parity checking
> _mpic_irq_read: val 0x80480004 shadow 0x80080014
> _mpic_irq_read: val 0x48000
Original-Nachricht
> Datum: Tue, 23 Jun 2009 23:42:24 +0200
> Von: "Gerhard Pircher"
> An: b...@kernel.crashing.org, ti...@suse.de
> CC: linuxppc-...@ozlabs.org
> Betreff: Re: ALSA fixes for non-coherent ppc32 again
> Okay, that's wrong. I somehow messed up the .config file. It
36 matches
Mail list logo
