Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
On Wed, 2009-06-24 at 15:56 +1000, Benjamin Herrenschmidt wrote:
On Wed, 2009-06-24 at 15:53 +1000, Michael Ellerman wrote:
Doesn't fix my machine :/
That doesn't make sense ... What if you remove the bit inside the ifdef
CONFIG_MPIC_BROKEN_REGREAD in _mpic_read() ?
If that makes a difference, then it would be interesting to add a printk
in there that prints what the original value val is and what we have
in the shadow...
With this patch it boots:
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 2353adc..fc17289 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -231,13 +231,16 @@ static inline u32 _mpic_irq_read(struct mpic *mpic, unsign
unsigned intisu = src_no mpic-isu_shift;
unsigned intidx = src_no mpic-isu_mask;
unsigned intval;
+ unsigned intshadow;
val = _mpic_read(mpic-reg_type, mpic-isus[isu],
reg + (idx * MPIC_INFO(IRQ_STRIDE)));
#ifdef CONFIG_MPIC_BROKEN_REGREAD
- if (reg == 0)
- val = (val (MPIC_VECPRI_MASK | MPIC_VECPRI_ACTIVITY)) |
+ if (reg == 0) {
+ shadow = (val (MPIC_VECPRI_MASK | MPIC_VECPRI_ACTIVITY)) |
mpic-isu_reg0_shadow[idx];
+ printk(%s: val 0x%x shadow 0x%x\n, __func__, val, shadow);
+ }
#endif
return val;
}
And I see:
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 0x480004 shadow 0x480004
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ALSA fixes for non-coherent ppc32 again
Original-Nachricht Datum: Tue, 23 Jun 2009 23:42:24 +0200 Von: Gerhard Pircher gerhard_pirc...@gmx.net 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 doesn't compile, too. I got it to compile now and it seems to work fine. I overlooked a typo in sound/core/Makefile first (ifndef CONFIG_SND_NONCOHERNT_DMA.) ^ I vote for a merge, if the config option and the typo is fixed. Ben, should I resend a properly formatted patch for the dma_mmap_coherent implementation or can we take the patch I already sent? Thanks! Gerhard -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
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 0x480004 shadow 0x480004 Strange.. it's like we read a different vector and polarity than what is in the cache. Oh well, I'll have a closer look tomorrow in the office. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ALSA fixes for non-coherent ppc32 again
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 gerhard_pirc...@gmx.net 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 doesn't compile, too. I got it to compile now and it seems to work fine. I overlooked a typo in sound/core/Makefile first (ifndef CONFIG_SND_NONCOHERNT_DMA.) Gah, thanks, fixed now on the git tree too. Takashi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
85xx Address space query
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 opens invokes a ioctl call and passes a buffer pointer ( say 0x1 in user space) Now the driver code is using copy_from_user. How this works internally ? 1. User code executes ioctl 2. interrupt goes to the kernel 3. ioctl handler in driver gets invoked The buffer pointer still contains 0x1. How kernel code running in PR=0 accesses it and does the copy. I am not able to see a address space switch in the asm code of copy_tofrom_user. Please respond -TRX ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] pseries: cpu: Reduce the polling interval in __cpu_up()
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 presence
through the cpu_callin_map. We repeat this operation until the new cpu sets
the value in cpu_callin_map or 5 seconds elapse, whichever comes earlier.
However, using completion_structs instead of polling loops,
the time taken by the new processor to indicate it's presence has
found to be less than 1ms on pseries. This method however may not
work on all powerpc platforms due to the time-base synchronization code.
Keeping this in mind, we could reduce msleep polling interval from
200ms to 1ms while retaining the 5 second timeout.
With this, the time taken for a cpu online operation changes as follows:
Dedicated LPAR (POWER6): 20-25ms.
Shared LPAR (POWER5) : 60-80ms.
In both these cases, it was found that the code polls through the loop
only once indicating that 1ms is a reasonable value, atleast on pseries.
The code needs testing on other powerpc platforms.
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
---
arch/powerpc/kernel/smp.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 65484b2..00c13a1 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -411,9 +411,8 @@ int __cpuinit __cpu_up(unsigned int cpu)
* CPUs can take much longer to come up in the
* hotplug case. Wait five seconds.
*/
- for (c = 25; c !cpu_callin_map[cpu]; c--) {
- msleep(200);
- }
+ for (c = 5000; c !cpu_callin_map[cpu]; c--)
+ msleep(1);
#endif
if (!cpu_callin_map[cpu]) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] net/gianfar: add missing set_mac_address hook
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 le...@freescale.com
Acked-by: Andy Fleming aflem...@freescale.com
---
drivers/net/gianfar.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 4ae1d25..f526c99 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -111,7 +111,6 @@ static int gfar_close(struct net_device *dev);
struct sk_buff *gfar_new_skb(struct net_device *dev);
static void gfar_new_rxbdp(struct net_device *dev, struct rxbd8 *bdp,
struct sk_buff *skb);
-static int gfar_set_mac_address(struct net_device *dev);
static int gfar_change_mtu(struct net_device *dev, int new_mtu);
static irqreturn_t gfar_error(int irq, void *dev_id);
static irqreturn_t gfar_transmit(int irq, void *dev_id);
@@ -142,6 +141,7 @@ void gfar_start(struct net_device *dev);
static void gfar_clear_exact_match(struct net_device *dev);
static void gfar_set_mac_for_addr(struct net_device *dev, int num, u8 *addr);
static int gfar_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
+static int gfar_set_mac_addr(struct net_device *dev, void *p)
MODULE_AUTHOR(Freescale Semiconductor, Inc);
MODULE_DESCRIPTION(Gianfar Ethernet Driver);
@@ -156,6 +156,7 @@ static const struct net_device_ops gfar_netdev_ops = {
.ndo_tx_timeout = gfar_timeout,
.ndo_do_ioctl = gfar_ioctl,
.ndo_vlan_rx_register = gfar_vlan_rx_register,
+ .ndo_set_mac_address = gfar_set_mac_addr,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = gfar_netpoll,
#endif
@@ -1182,7 +1183,7 @@ static int gfar_enet_open(struct net_device *dev)
/* Initialize a bunch of registers */
init_registers(dev);
- gfar_set_mac_address(dev);
+ gfar_set_mac_for_addr(dev, 0, dev-dev_addr);
err = init_phy(dev);
@@ -1426,15 +1427,19 @@ static int gfar_close(struct net_device *dev)
return 0;
}
-/* Changes the mac address if the controller is not running. */
-static int gfar_set_mac_address(struct net_device *dev)
+/* Changes the station mac address on the go */
+static int gfar_set_mac_addr(struct net_device *dev, void *p)
{
- gfar_set_mac_for_addr(dev, 0, dev-dev_addr);
+ struct sockaddr *addr = p;
+
+ if (!is_valid_ether_addr(addr-sa_data))
+ return -EADDRNOTAVAIL;
+ memcpy(dev-dev_addr, addr-sa_data, ETH_ALEN);
+ gfar_set_mac_for_addr(dev, 0, dev-dev_addr);
return 0;
}
-
/* Enables and disables VLAN insertion/extraction */
static void gfar_vlan_rx_register(struct net_device *dev,
struct vlan_group *grp)
--
1.6.3.1.6.g4bf1f
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 85xx Address space query
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. correct. (b) I am writing a small program where the application code opens invokes a ioctl call and passes a buffer pointer ( say 0x1 in user space) Now the driver code is using copy_from_user. How this works internally ? 1. User code executes ioctl 2. interrupt goes to the kernel On the interrupt the PR changes from 0 - 1 3. ioctl handler in driver gets invoked The buffer pointer still contains 0x1. How kernel code running in PR=0 accesses it and does the copy. I am not able to see a address space switch in the asm code of copy_tofrom_user. There isn't a address space switch. But address spaces exist at the same time. The user app is given 0..0xc000_ and the kernel uses 0xc000_..0x_. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Question] m25p80 driver versus spi clock rate
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 / SPI linkage problem. Namely, of_register_spi_devices does not support a bits-per-word property, so bits-per-word is zero. Bits-per-word == 0 must be interpreted as == 8. Simple bug in the ppc4xx code. It currently rejects values other than 8. Ok - I'll post a patch for that. Your changes to bitbang_work look good. 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 sfa...@harris.com 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. Perhaps when I post my patch to the PPC list, we can move this further along... Steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Question] m25p80 driver versus spi clock rate
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. Perhaps when I post my patch to the PPC list, we can move this further along... 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 pick up here and resubmit this driver so that we can get it finally included. Thanks. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v1] Make spi_ppc4xx.c tolerate 0 bits-per-word and 0 speed_hz
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 parameters
are used.
Additionally, since there is no OF binding for bits-per-word, we have to
tolerate the case where both t-bits_per_word and spi-bits_per_word are
zero.
---
This was brought to light by a pending patch to spi_bitbang, which results
in more calls to spi_ppc4xx_setupxfer.
drivers/spi/spi_ppc4xx.c | 22 +++---
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi_ppc4xx.c b/drivers/spi/spi_ppc4xx.c
index e46292b..9775bf2 100644
--- a/drivers/spi/spi_ppc4xx.c
+++ b/drivers/spi/spi_ppc4xx.c
@@ -151,16 +151,24 @@ static int spi_ppc4xx_setupxfer(struct spi_device *spi,
struct spi_transfer *t)
/* Write new configration */
out_8(hw-regs-mode, cs-mode);
+ /* Start with the generic configuration for this device. */
+ bpw = spi-bits_per_word;
+ cs-speed_hz = spi-max_speed_hz;
+
/*
-* Allow platform reduce the interrupt load on the CPU during SPI
-* transfers. We do not target maximum performance, but rather allow
-* platform to limit SPI bus frequency and interrupt rate.
+* Allow the platform to reduce the interrupt load on the CPU during
+* SPI transfers. We do not target maximum performance, but rather
+* allow the platform to limit SPI bus frequency and interrupt rate.
*/
- bpw = t ? t-bits_per_word : spi-bits_per_word;
- cs-speed_hz = t ? min(t-speed_hz, spi-max_speed_hz) :
- spi-max_speed_hz;
+ if(t) {
+ if(t-bits_per_word)
+ bpw = t-bits_per_word;
+
+ if(t-speed_hz)
+ cs-speed_hz = min(t-speed_hz, spi-max_speed_hz);
+ }
- if (bpw != 8) {
+ if (bpw bpw != 8) {
dev_err(spi-dev, invalid bits-per-word (%d)\n, bpw);
return -EINVAL;
}
--
1.6.0.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Question] m25p80 driver versus spi clock rate
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 question for Stefan. Perhaps when I post my patch to the PPC list, we can move this further along... 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 pick up here and resubmit this driver so that we can get it finally included. Thanks. Best regards, Stefan Ok - I'll take that on. Please, both David and Stefan send me the latest versions and/or patches you have, and I'll integrate them and post to the PPC list. Steve -- A: Because it makes the logic of the discussion difficult to follow. Q: Why shouldn't I top post? A: No. Q: Should I top post? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Question] m25p80 driver versus spi clock rate
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 pick up here and resubmit this driver so that we can get it finally included. Thanks. Best regards, Stefan Ok - I'll take that on. Great, thanks. Please, both David and Stefan send me the latest versions and/or patches you have, and I'll integrate them and post to the PPC list. I just sent you my latest driver version (v6). Here a link to David's latest review: http://article.gmane.org/gmane.linux.ports.ppc64.devel/55229 Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Question] m25p80 driver versus spi clock rate
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 sfa...@harris.com The -1 is for the init path, 1 for per-transfer overrides; this way it avoids some extra calls to set up the bits/speed. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Question] m25p80 driver versus spi clock rate
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-word and 0 speed_hz I was successful in operating both the m25p16 at 16 MHz and the AVR at 240 KHz, as verified by oscilloscope. So my ack includes testing. 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 sfa...@harris.com The -1 is for the init path, 1 for per-transfer overrides; this way it avoids some extra calls to set up the bits/speed. Got it. No further comments. My ack stands. I'll start looking at a revised version of the spi_ppc4xx.c driver, integrating your comments. Steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Fix ethernet link detection on MPC8569E-MDS boards
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 extract it from the device tree and pass it to phydevs, but
that'll be quite a lot of work), so for now just reset the PHYs to
their default states.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 3268c95..34664c0 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -223,6 +223,19 @@ static void __init mpc85xx_mds_setup_arch(void)
/* Turn UCC1 UCC2 on */
setbits8(bcsr_regs[8], BCSR_UCC1_GETH_EN);
setbits8(bcsr_regs[9], BCSR_UCC2_GETH_EN);
+ } else if (machine_is(mpc8569_mds)) {
+#define BCSR7_UCC12_GETHnRST (0x1 2)
+#define BCSR8_UEM_MARVELL_RST (0x1 1)
+ /*
+* U-Boot mangles interrupt polarity for Marvell PHYs,
+* so reset built-in and UEM Marvell PHYs, this puts
+* the PHYs into their normal state.
+*/
+ clrbits8(bcsr_regs[7], BCSR7_UCC12_GETHnRST);
+ setbits8(bcsr_regs[8], BCSR8_UEM_MARVELL_RST);
+
+ setbits8(bcsr_regs[7], BCSR7_UCC12_GETHnRST);
+ clrbits8(bcsr_regs[8], BCSR8_UEM_MARVELL_RST);
}
iounmap(bcsr_regs);
}
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] pseries: cpu: Reduce the polling interval in __cpu_up()
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 jsch...@austin.ibm.com
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
---
arch/powerpc/kernel/smp.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 65484b2..00c13a1 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -411,9 +411,8 @@ int __cpuinit __cpu_up(unsigned int cpu)
* CPUs can take much longer to come up in the
* hotplug case. Wait five seconds.
*/
- for (c = 25; c !cpu_callin_map[cpu]; c--) {
- msleep(200);
- }
+ for (c = 5000; c !cpu_callin_map[cpu]; c--)
+ msleep(1);
#endif
if (!cpu_callin_map[cpu]) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ucc_geth: Fix half-duplex operation for non-MII/RMII interfaces
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)
[...]
Sending DHCP and RARP requests .
PHY: m...@e0082120:07 - Link is Up - 10/Half
., OK
[...]
Looking up port of RPC 13/2 on 10.0.0.2
Looking up port of RPC 15/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:13.
Freeing unused kernel memory: 204k init
eth0: no IPv6 routers present
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
The statistic shows that there are indeed some errors:
# ethtool -S eth0 | grep -v : 0
NIC statistics:
tx-64-frames: 42
tx-65-127-frames: 9
tx-128-255-frames: 4768
rx-64-frames: 41
rx-65-127-frames: 260
rx-128-255-frames: 2679
tx-bytes-ok: 859634
tx-multicast-frames: 5
tx-broadcast-frames: 7
rx-frames: 8333
rx-bytes-ok: 8039364
rx-bytes-all: 8039364
stats-counter-mask: 4294901760
tx-single-collision: 324
tx-multiple-collision: 47
tx-late-collsion: 604
tx-aborted-frames: 604
tx-frames-ok: 4967
tx-256-511-frames: 3
tx-512-1023-frames: 79
tx-1024-1518-frames: 71
rx-256-511-frames: 37
rx-512-1023-frames: 73
rx-1024-1518-frames: 5243
According to current QEIWRM (Rev. 2 5/2009), FDX bit can be 0 for
RGMII(10/100) modes, while MPC8568ERM (Rev. C 02/2007) spec says
that cleared FDX bit is permitted for MII/RMII modes only.
The symptoms above were seen on MPC8569E-MDS boards, so QEIWRM is
clearly wrong, and this patch completely cures the problems above.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/net/ucc_geth.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 464df03..e618cf2 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1469,12 +1469,16 @@ static void adjust_link(struct net_device *dev)
if (phydev-link) {
u32 tempval = in_be32(ug_regs-maccfg2);
u32 upsmr = in_be32(uf_regs-upsmr);
+ phy_interface_t phyi = ugeth-phy_interface;
+
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev-duplex != ugeth-oldduplex) {
new_state = 1;
- if (!(phydev-duplex))
- tempval = ~(MACCFG2_FDX);
+ if (!phydev-duplex
+ (phyi == PHY_INTERFACE_MODE_MII ||
+phyi == PHY_INTERFACE_MODE_RMII))
+ tempval = ~MACCFG2_FDX;
else
tempval |= MACCFG2_FDX;
ugeth-oldduplex = phydev-duplex;
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support
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 le...@freescale.com However, the addition of arch/powerpc/include/asm/fsldma.h still needs the ack from Kumar. It doesn't seem to be a common practice though. hmm, why are we moving fsldma.h? There are now two fsldma.h files. drivers/dma/fsldma.h: no changes, houses the private driver implementation details. arch/powerpc/include/asm/fsldma.h: adds some helper routines and definitions for the DMA_SLAVE capability of the driver. It defines an interface for other drivers to use fsldma to initiate device-to-memory dma. Any drivers that use the interface will depend on CONFIG_FSL_DMA hence placing this public header under arch/powerpc/include. Kumar? Shall we push this decision off to 2.6.32, I would prefer not to as Ira had his initial patches available before the merge window opened? Ira, aside from the pci read multiple patch are there any others that are suitable for 2.6.31 if the dma_slave implementation gets held back? Thanks, Dan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
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
[...]
Sending DHCP requests .
PHY: m...@e0024520:02 - Link is Up - 10/Half
., OK
[...]
Looking up port of RPC 13/2 on 10.0.0.2
Looking up port of RPC 15/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:11.
Freeing unused kernel memory: 188k init
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
And just as with ucc_geth, statistic shows errors:
# ethtool -S eth0 | grep -v : 0
NIC statistics:
rx-dropped-by-kernel: 2
tx-rx-64-frames: 49
tx-rx-65-127-frames: 1270
tx-rx-128-255-frames: 9992
tx-rx-256-511-frames: 75
tx-rx-512-1023-frames: 142
tx-rx-1024-1518-frames: 8828
rx-bytes: 13299414
rx-packets: 13122
rx-jabber-frames: 9
tx-byte-counter: 1284847
tx-packets: 8115
tx-broadcast-packets: 3
tx-deferral-packets: 43
tx-single-collision-packets: 15
tx-multiple-collision-packets: 301
tx-late-collision-packets: 872
tx-total-collision: 999
tx-undersize-frames: 6
The symptoms were observed on MPC8379E-RDB boards (eTSEC). Although
I didn't find where documentation forbids clearing Full Duplex bit
for non-MII/RMII modes, it's pretty distinct that the bit should be
set.
It's no wonder though, QE Ethernet and TSEC are pretty similar.
[1] http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073631.html
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/net/gianfar.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8741bb0..15dbffa 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1984,13 +1984,16 @@ static void adjust_link(struct net_device *dev)
if (phydev-link) {
u32 tempval = gfar_read(regs-maccfg2);
u32 ecntrl = gfar_read(regs-ecntrl);
+ phy_interface_t phyi = phydev-interface;
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev-duplex != priv-oldduplex) {
new_state = 1;
- if (!(phydev-duplex))
- tempval = ~(MACCFG2_FULL_DUPLEX);
+ if (!phydev-duplex
+ (phyi == PHY_INTERFACE_MODE_MII ||
+phyi == PHY_INTERFACE_MODE_RMII))
+ tempval = ~MACCFG2_FULL_DUPLEX;
else
tempval |= MACCFG2_FULL_DUPLEX;
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support
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 le...@freescale.com However, the addition of arch/powerpc/include/asm/fsldma.h still needs the ack from Kumar. It doesn't seem to be a common practice though. hmm, why are we moving fsldma.h? There are now two fsldma.h files. drivers/dma/fsldma.h: no changes, houses the private driver implementation details. arch/powerpc/include/asm/fsldma.h: adds some helper routines and definitions for the DMA_SLAVE capability of the driver. It defines an interface for other drivers to use fsldma to initiate device-to- memory dma. Any drivers that use the interface will depend on CONFIG_FSL_DMA hence placing this public header under arch/powerpc/ include. Kumar? Shall we push this decision off to 2.6.32, I would prefer not to as Ira had his initial patches available before the merge window opened? Ira, aside from the pci read multiple patch are there any others that are suitable for 2.6.31 if the dma_slave implementation gets held back? Lets go ahead w/2.6.31 (if its ok w/you). - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
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 where documentation forbids clearing Full Duplex bit for non-MII/RMII modes, it's pretty distinct that the bit should be set. It's no wonder though, QE Ethernet and TSEC are pretty similar. - if (!(phydev-duplex)) - tempval = ~(MACCFG2_FULL_DUPLEX); + if (!phydev-duplex + (phyi == PHY_INTERFACE_MODE_MII || +phyi == PHY_INTERFACE_MODE_RMII)) Hmmhave you tested this on a GMII interface? *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 via this code, just below: case 100: case 10: tempval = ((tempval ~(MACCFG2_IF)) | MACCFG2_MII); 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. Andy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support
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.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
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 symptoms were observed on MPC8379E-RDB boards (eTSEC). Although I didn't find where documentation forbids clearing Full Duplex bit for non-MII/RMII modes, it's pretty distinct that the bit should be set. It's no wonder though, QE Ethernet and TSEC are pretty similar. -if (!(phydev-duplex)) -tempval = ~(MACCFG2_FULL_DUPLEX); +if (!phydev-duplex +(phyi == PHY_INTERFACE_MODE_MII || + phyi == PHY_INTERFACE_MODE_RMII)) Hmmhave you tested this on a GMII interface? Nope, only RGMII. *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 via this code, just below: case 100: case 10: tempval = ((tempval ~(MACCFG2_IF)) | MACCFG2_MII); 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 completely following. :-) Are you saying that I should do this instead: if (!phydev-duplex (phyi == PHY_INTERFACE_MODE_MII || phyi == PHY_INTERFACE_MODE_RMII || (phyi == PHY_INTERFACE_MODE_GMII phydev-speed 1000))) tempval = ~MACCFG2_FULL_DUPLEX; else tempval |= MACCFG2_FULL_DUPLEX; i.e. we detected GMII interface initially, but it downgraded to MII since speed is 1000, thus we can set half-duplex in MAC? Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
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 completely following. :-) Are you saying that I should do this instead: if (!phydev-duplex (phyi == PHY_INTERFACE_MODE_MII || phyi == PHY_INTERFACE_MODE_RMII || (phyi == PHY_INTERFACE_MODE_GMII phydev-speed 1000))) tempval = ~MACCFG2_FULL_DUPLEX; else tempval |= MACCFG2_FULL_DUPLEX; i.e. we detected GMII interface initially, but it downgraded to MII since speed is 1000, thus we can set half-duplex in MAC? Yeah, I think that works out more correctly. Cool, thanks. Do you happen to know how gianfar iface auto-detection works in HW? I mean, if we connect 100 Mbs link to the GMII PHY, then gfar_get_interface() would return MII, correct? If so, then I think I'll also have to change phy_interface_t phyi = phydev-interface; to phy_interface_t phyi = gfar_get_interface(dev); since phydev-interface may contain outdated information. Or this can't happen? And I suspect that the same is true for UCC Yup. Much thanks for catching this! -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
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 running at 10 or 100 Mbit. Very interesting, though I'm not sure I'm completely following. :-) Are you saying that I should do this instead: if (!phydev-duplex (phyi == PHY_INTERFACE_MODE_MII || phyi == PHY_INTERFACE_MODE_RMII || (phyi == PHY_INTERFACE_MODE_GMII phydev-speed 1000))) tempval = ~MACCFG2_FULL_DUPLEX; else tempval |= MACCFG2_FULL_DUPLEX; i.e. we detected GMII interface initially, but it downgraded to MII since speed is 1000, thus we can set half-duplex in MAC? Yeah, I think that works out more correctly. Cool, thanks. Do you happen to know how gianfar iface auto-detection works in HW? I mean, if we connect 100 Mbs link to the GMII PHY, then gfar_get_interface() would return MII, correct? Stupid me. HW has nothing to do with this. GMII, just as you said, is just a marker, comes from FSL_GIANFAR_DEV_HAS_GIGABIT flag. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 85xx Address space query
On Wed, Jun 24, 2009 at 6:45 PM, Kumar Galaga...@kernel.crashing.org 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 space application run in PR=1 AS=0 and PID 1-255. Is this correct. correct. (b) I am writing a small program where the application code opens invokes a ioctl call and passes a buffer pointer ( say 0x1 in user space) Now the driver code is using copy_from_user. How this works internally ? 1. User code executes ioctl 2. interrupt goes to the kernel On the interrupt the PR changes from 0 - 1 3. ioctl handler in driver gets invoked The buffer pointer still contains 0x1. How kernel code running in PR=0 accesses it and does the copy. I am not able to see a address space switch in the asm code of copy_tofrom_user. There isn't a address space switch. But address spaces exist at the same time. The user app is given 0..0xc000_ and the kernel uses 0xc000_..0x_. Ah Ok, I get it Thanks Kumar 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 - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
*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 via this code, just below: case 100: case 10: tempval = ((tempval ~(MACCFG2_IF)) | MACCFG2_MII); 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 completely following. :-) Are you saying that I should do this instead: if (!phydev-duplex (phyi == PHY_INTERFACE_MODE_MII || phyi == PHY_INTERFACE_MODE_RMII || (phyi == PHY_INTERFACE_MODE_GMII phydev-speed 1000))) tempval = ~MACCFG2_FULL_DUPLEX; else tempval |= MACCFG2_FULL_DUPLEX; i.e. we detected GMII interface initially, but it downgraded to MII since speed is 1000, thus we can set half-duplex in MAC? Yeah, I think that works out more correctly. And I suspect that the same is true for UCC Andy___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 85xx Address space query
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 register. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How the kernel printk works before do console_setup.
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 subsequent printks cause the message to go to the log buffer, but then immediately get sent from there to the console. Under certain conditions you can examine the log buffer of a kernel that failed to initialize it's console, after a warm reset of the machine, using the firmware memory dump command. On ppc, we have tricks to display things earlier :-) We can initialize the serial ports way before console_setup() (and we do in most cases) and we use what we call the udbg console until the real one takes over. The udbg console is a very small layer which outputs via a provided putc routine. Platforms can provide their own here, we have a collection of standard ones for legacy UARTs (it should be automatically setup in that case by the code in legacy_serial), Apple ESCCs, etc... We even have compile time options that allow that stuff to be initialized before start_kernel... Cheers, Ben. See http://elinux.org/Kernel_Debugging_Tips#Accessing_the_printk_buffer_after_a_silent_hang_on_boot for some tips on accessing the log buffer of a previous boot. Note also, that if the serial console does not come up, but the kernel successfully boots, and you can get a network login on the machine, you can always print out the kernel log buffer messages using 'dmesg' at a user-space shell prompt. Hope this helps! -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/2] ucc_geth: Fix half-duplex operation for non-MII/RMII interfaces
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 DHCP and RARP requests .
PHY: m...@e0082120:07 - Link is Up - 10/Half
., OK
[...]
Looking up port of RPC 13/2 on 10.0.0.2
Looking up port of RPC 15/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:13.
Freeing unused kernel memory: 204k init
eth0: no IPv6 routers present
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
The statistic shows that there are indeed some errors:
# ethtool -S eth0 | grep -v : 0
NIC statistics:
tx-64-frames: 42
tx-65-127-frames: 9
tx-128-255-frames: 4768
rx-64-frames: 41
rx-65-127-frames: 260
rx-128-255-frames: 2679
tx-bytes-ok: 859634
tx-multicast-frames: 5
tx-broadcast-frames: 7
rx-frames: 8333
rx-bytes-ok: 8039364
rx-bytes-all: 8039364
stats-counter-mask: 4294901760
tx-single-collision: 324
tx-multiple-collision: 47
tx-late-collsion: 604
tx-aborted-frames: 604
tx-frames-ok: 4967
tx-256-511-frames: 3
tx-512-1023-frames: 79
tx-1024-1518-frames: 71
rx-256-511-frames: 37
rx-512-1023-frames: 73
rx-1024-1518-frames: 5243
According to current QEIWRM (Rev. 2 5/2009), FDX bit can be 0 for
RGMII(10/100) modes, while MPC8568ERM (Rev. C 02/2007) spec says
that cleared FDX bit is permitted for MII/RMII modes only.
The symptoms above were seen on MPC8569E-MDS boards, so QEIWRM is
clearly wrong, and this patch completely cures the problems above.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/net/ucc_geth.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 464df03..0c26a59 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1469,12 +1469,18 @@ static void adjust_link(struct net_device *dev)
if (phydev-link) {
u32 tempval = in_be32(ug_regs-maccfg2);
u32 upsmr = in_be32(uf_regs-upsmr);
+ phy_interface_t phyi = ugeth-phy_interface;
+
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev-duplex != ugeth-oldduplex) {
new_state = 1;
- if (!(phydev-duplex))
- tempval = ~(MACCFG2_FDX);
+ if (!phydev-duplex
+ (phyi == PHY_INTERFACE_MODE_MII ||
+phyi == PHY_INTERFACE_MODE_RMII ||
+(phyi == PHY_INTERFACE_MODE_GMII
+ phydev-speed 1000)))
+ tempval = ~MACCFG2_FDX;
else
tempval |= MACCFG2_FDX;
ugeth-oldduplex = phydev-duplex;
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/2] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
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
[...]
Sending DHCP requests .
PHY: m...@e0024520:02 - Link is Up - 10/Half
., OK
[...]
Looking up port of RPC 13/2 on 10.0.0.2
Looking up port of RPC 15/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:11.
Freeing unused kernel memory: 188k init
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
And just as with ucc_geth, statistic shows errors:
# ethtool -S eth0 | grep -v : 0
NIC statistics:
rx-dropped-by-kernel: 2
tx-rx-64-frames: 49
tx-rx-65-127-frames: 1270
tx-rx-128-255-frames: 9992
tx-rx-256-511-frames: 75
tx-rx-512-1023-frames: 142
tx-rx-1024-1518-frames: 8828
rx-bytes: 13299414
rx-packets: 13122
rx-jabber-frames: 9
tx-byte-counter: 1284847
tx-packets: 8115
tx-broadcast-packets: 3
tx-deferral-packets: 43
tx-single-collision-packets: 15
tx-multiple-collision-packets: 301
tx-late-collision-packets: 872
tx-total-collision: 999
tx-undersize-frames: 6
The symptoms were observed on MPC8379E-RDB boards (eTSEC). Although
I didn't find where documentation forbids clearing Full Duplex bit
for non-MII/RMII modes, it's pretty distinct that the bit should be
set for RGMII.
It's no wonder though, QE Ethernet and TSEC are pretty similar.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/net/gianfar.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8741bb0..503b455 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1984,13 +1984,18 @@ static void adjust_link(struct net_device *dev)
if (phydev-link) {
u32 tempval = gfar_read(regs-maccfg2);
u32 ecntrl = gfar_read(regs-ecntrl);
+ phy_interface_t phyi = phydev-interface;
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev-duplex != priv-oldduplex) {
new_state = 1;
- if (!(phydev-duplex))
- tempval = ~(MACCFG2_FULL_DUPLEX);
+ if (!phydev-duplex
+ (phyi == PHY_INTERFACE_MODE_MII ||
+phyi == PHY_INTERFACE_MODE_RMII ||
+(phyi == PHY_INTERFACE_MODE_GMII
+ phydev-speed 1000)))
+ tempval = ~MACCFG2_FULL_DUPLEX;
else
tempval |= MACCFG2_FULL_DUPLEX;
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Add EDAC support for P2020DS
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 that EDAC core can recognize
DDR3 memory type.
Signed-off-by: Yang Shi yang@windriver.com
---
(85xx DDR3 EDAC patch is currently in akpm's mm tree)
drivers/edac/mpc85xx_edac.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 7c8c2d7..85575fb 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -646,6 +646,7 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{ .compatible = fsl,mpc8560-l2-cache-controller, },
{ .compatible = fsl,mpc8568-l2-cache-controller, },
{ .compatible = fsl,mpc8572-l2-cache-controller, },
+ { .compatible = fsl,p2020-l2-cache-controller, },
{},
};
@@ -978,6 +979,7 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{ .compatible = fsl,mpc8560-memory-controller, },
{ .compatible = fsl,mpc8568-memory-controller, },
{ .compatible = fsl,mpc8572-memory-controller, },
+ { .compatible = fsl,p2020-memory-controller, },
{},
};
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mpc85xx: Create dts for each core in CAMP mode for P2020DS
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, eth1, crypto, pci0,
pci1, usb, spi, sdhci.
core1: L2, dma2, eth2, pci2, msi.
Based on MPC8572DS CAMP dts files.
(commit 361425fc32422c9716fc69e52455b7d44fc02c18)
Signed-off-by: Yang Shi yang@windriver.com
---
arch/powerpc/boot/dts/p2020ds_camp_core0.dts | 457 ++
arch/powerpc/boot/dts/p2020ds_camp_core1.dts | 209
2 files changed, 666 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p2020ds_camp_core0.dts
create mode 100644 arch/powerpc/boot/dts/p2020ds_camp_core1.dts
diff --git a/arch/powerpc/boot/dts/p2020ds_camp_core0.dts
b/arch/powerpc/boot/dts/p2020ds_camp_core0.dts
new file mode 100644
index 000..5d74a9c
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020ds_camp_core0.dts
@@ -0,0 +1,457 @@
+/*
+ * P2020 DS Core0 Device Tree Source in CAMP mode.
+ *
+ * In CAMP mode, each core needs to have its own dts. Only mpic and L2 cache
+ * can be shared, all the other devices must be assigned to one core only.
+ * This dts file allows core0 to have memory, l2, i2c, dma1, global-util, eth0,
+ * eth1, crypto, usb, spi, sdhci, pci0, pci1.
+ *
+ * Copyright 2009 Wind River Systems Inc.
+ *
+ * Based largely on the P2020DS SMP and MPC8572DS CAMP DTS which are:
+ *
+ *Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,P2020;
+ compatible = fsl,P2020DS, fsl,MPC8572DS-CAMP;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ serial0 = serial0;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ s...@ffe0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = fsl,p2020-immr, simple-bus;
+ ranges = 0x0 0xffe0 0x10;
+ bus-frequency = 0;// Filled out by uboot.
+
+ ecm-...@0 {
+ compatible = fsl,ecm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 12;
+ };
+
+ e...@1000 {
+ compatible = fsl,p2020-ecm, fsl,ecm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
+ memory-control...@2000 {
+ compatible = fsl,p2020-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 2;
+ };
+
+ i...@3000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ i...@3100 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ enet0: ether...@24000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ cell-index = 0;
+ device_type = network;
+ model = eTSEC;
+ compatible = gianfar;
+ reg = 0x24000 0x1000;
+ ranges = 0x0 0x24000 0x1000;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = 29 2 30 2 34 2;
+ interrupt-parent = mpic;
+ phy-handle = phy0;
+ phy-connection-type =
Re: [PATCH] ucc_geth: Fix half-duplex operation for non-MII/RMII interfaces
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 (irq = 32)
[...]
Sending DHCP and RARP requests .
PHY: m...@e0082120:07 - Link is Up - 10/Half
., OK
So why does the phy think this is a half-duplex network?
[...]
Looking up port of RPC 13/2 on 10.0.0.2
Looking up port of RPC 15/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:13.
Freeing unused kernel memory: 204k init
eth0: no IPv6 routers present
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
The statistic shows that there are indeed some errors:
# ethtool -S eth0 | grep -v : 0
NIC statistics:
tx-64-frames: 42
tx-65-127-frames: 9
tx-128-255-frames: 4768
rx-64-frames: 41
rx-65-127-frames: 260
rx-128-255-frames: 2679
tx-bytes-ok: 859634
tx-multicast-frames: 5
tx-broadcast-frames: 7
rx-frames: 8333
rx-bytes-ok: 8039364
rx-bytes-all: 8039364
stats-counter-mask: 4294901760
tx-single-collision: 324
tx-multiple-collision: 47
tx-late-collsion: 604
tx-aborted-frames: 604
The above two counters are the actual errors from a half-duplex ethernet
configuration. The size of the collision domain is limited so that the
collisions from one end will reach the other end within the minimum
frame length wire time. Thus the collision will be detected within the
first 64 bytes of the frame. A late collision indicates a
mis-configured network. The fact that everything seems to work when the
MAC is placed into full-duplex mode hints that the network is really a
full-duplex network.
Otherwise, if the network is really half-duplex, then presence of a
full-duplex node will result in the other nodes seeing CRC/framing
errors on receive, and possibly also late collisions, as the full-duplex
node does not observe the CS or the CD( carrier sense and collision
detect) part of CSMA/CD, because it doesn't care.
Putting a node in full-duplex will always make the nasty collision
related errors go away, but it may not be a proper diagnosis of the problem.
tx-frames-ok: 4967
tx-256-511-frames: 3
tx-512-1023-frames: 79
tx-1024-1518-frames: 71
rx-256-511-frames: 37
rx-512-1023-frames: 73
rx-1024-1518-frames: 5243
According to current QEIWRM (Rev. 2 5/2009), FDX bit can be 0 for
RGMII(10/100) modes, while MPC8568ERM (Rev. C 02/2007) spec says
that cleared FDX bit is permitted for MII/RMII modes only.
The symptoms above were seen on MPC8569E-MDS boards, so QEIWRM is
clearly wrong, and this patch completely cures the problems above.
Not so fast - RGMII and GMII refer to the interface between the MAC and
the PHY. While Gigabit physical links will always be full-duplex, phys
that detect lower operational modes will indicate half-duplex where
needed, and putting the MAC into full-duplex will make other nodes see
errors.
As Andy indicated later, it may be necessary to alter the interface
definition in those cases, depending on the particular hardware.
Forcing full-duplex does not seem to be a general solution.
Mark Huth
MontaVista Software
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/net/ucc_geth.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 464df03..e618cf2 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1469,12 +1469,16 @@ static void adjust_link(struct net_device *dev)
if (phydev-link) {
u32 tempval = in_be32(ug_regs-maccfg2);
u32 upsmr = in_be32(uf_regs-upsmr);
+ phy_interface_t phyi = ugeth-phy_interface;
+
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev-duplex != ugeth-oldduplex) {
new_state = 1;
- if (!(phydev-duplex))
- tempval = ~(MACCFG2_FDX);
+ if (!phydev-duplex
+ (phyi == PHY_INTERFACE_MODE_MII ||
+phyi == PHY_INTERFACE_MODE_RMII))
+ tempval = ~MACCFG2_FDX;
else
tempval |= MACCFG2_FDX;
ugeth-oldduplex = phydev-duplex;
