RE: Bug in drivers/serial/of_serial.c?
Hi,
On Monday, November 16, 2009, Arnd wrote:
- { .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550, },
+ { .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550A, },
Does not seem logical. If the device claims compatibility with
ns16550, we should
not automatically assume it's an ns16550a. Why not add another line
for
Unfortunately, there is no way to change what the device claims--it's
encoded into the OpenFirmware tree by the EDK tools.
And, in any case, the device is actually not lying: it _is_ compatible
with NS16550--just with a non-buggy one. Unfortunately the kernel
driver for 8250-class UARTs makes the conservative choice to assume any
16550 is one of the (early, buggy) revisions where the FIFO was
non-functional; any 16550 with working UART is classed as a 16550A.
-az
**
IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the
named recipient(s) only.
If you have received this email in error, please notify the system manager or
the sender immediately and do
not disclose the contents to anyone or make copies thereof.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH/RFC] Booting Xilinx ML510 board using SystemACE
Hi, On Monday, November 16, 2009, Stephen wrote: There are at least two other ways that you might be able to reset a board: 1) Internally through the ICAP device. 2) Through a GPIO connected externally to the reset logic. Unfortunately none of these is relevant for the specific board in question (Xilinx ML510 reference system)... Probably it would be best to have a mechanism in the device tree which references the reset mechanism? I am sorely lacking in expertise for this :(, and wouldn't even know where to begin... Is it possible at all to add custom information into the device tree? And even if yes--how will platform code bind to the reset mechanism? [...] In any event, you probably don't want a driver to eplicitly reference the plaform code. If you want to do it explicitly like this, it would better to have the plaform code reference the driver mechanism. I don't see how this can be done: if the driver is to publish some driver_reset_system function to the platform code, it needs _some_ mechanism for telling this fact to the system... And such a mechanism won't look all that different from my callback, IMO (except it may be slightly prettied up). Of course, one obvious thing that must be done is move this code out of arch/powerpc/platforms/44x/virtex.c and into (e.g.) arch/powerpc/kernel/setup-common.c, and add some set_machine_restart_function wrapper to access it more cleanly (also defining this function as a null function when inapplicable). If this satisfies your standards, I can easily post an updated patch :) -az ** IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error, please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies thereof. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Bug in drivers/serial/of_serial.c?
On Thursday 19 November 2009, Alon Ziv wrote:
On Monday, November 16, 2009, Arnd wrote:
- { .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550, },
+ { .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550A, },
Does not seem logical. If the device claims compatibility with
ns16550, we should
not automatically assume it's an ns16550a. Why not add another line
for
Unfortunately, there is no way to change what the device claims--it's
encoded into the OpenFirmware tree by the EDK tools.
And, in any case, the device is actually not lying: it is compatible
with NS16550--just with a non-buggy one. Unfortunately the kernel
driver for 8250-class UARTs makes the conservative choice to assume any
16550 is one of the (early, buggy) revisions where the FIFO was
non-functional; any 16550 with working UART is classed as a 16550A.
In that case, add another entry for the device encoded in the firmware
itself. The ns16550 entry should be the second one after a more specific
one telling which device it is exactly.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Bug in drivers/serial/of_serial.c?
Hi,
On Thursday, November 19, 2009, Arnd wrote:
In that case, add another entry for the device encoded in the firmware
itself. The ns16550 entry should be the second one after a more
specific
one telling which device it is exactly.
Is the following better?
---
[PATCH] Xilinx 16550 UART is actually 16550A-compatible
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 02406ba..40bf8f4 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -161,6 +161,7 @@ static int of_platform_serial_remove(struct
of_device *ofdev)
static struct of_device_id __devinitdata of_platform_serial_table[] = {
{ .type = serial, .compatible = ns8250, .data = (void
*)PORT_8250, },
{ .type = serial, .compatible = ns16450, .data = (void
*)PORT_16450, },
+ { .type = serial, .compatible = xlnx,xps-uart16550-2.00.b,
.data = (void *)PORT_16550A, },
{ .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550, },
{ .type = serial, .compatible = ns16750, .data = (void
*)PORT_16750, },
{ .type = serial, .compatible = ns16850, .data = (void
*)PORT_16850, },
**
IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the
named recipient(s) only.
If you have received this email in error, please notify the system manager or
the sender immediately and do
not disclose the contents to anyone or make copies thereof.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Bug in drivers/serial/of_serial.c?
On Thursday 19 November 2009, Alon Ziv wrote: Is the following better? --- [PATCH] Xilinx 16550 UART is actually 16550A-compatible Yes, that's better because it's guaranteed not to break any other system, while fixing yours. I'd still add support for the compatible=ns16550a property so that we do the right thing for future systems. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Bug in drivers/serial/of_serial.c?
On Thursday, November 19, 2009, Arnd Bergmann wrote:
I'd still add support for the compatible=ns16550a property
so that we do the right thing for future systems.
OK...
---
Xilinx 16550 UART is actually 16550A-compatible
Signed-off-by: Alon Ziv al...@discretix.com
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 02406ba..241be77 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
of_device *ofdev)
static struct of_device_id __devinitdata of_platform_serial_table[] = {
{ .type = serial, .compatible = ns8250, .data = (void
*)PORT_8250, },
{ .type = serial, .compatible = ns16450, .data = (void
*)PORT_16450, },
+ { .type = serial, .compatible = xlnx,xps-uart16550-2.00.b,
.data = (void *)PORT_16550A, },
{ .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550, },
+ { .type = serial, .compatible = ns16550a, .data = (void
*)PORT_16550A, },
{ .type = serial, .compatible = ns16750, .data = (void
*)PORT_16750, },
{ .type = serial, .compatible = ns16850, .data = (void
*)PORT_16850, },
#ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
**
IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the
named recipient(s) only.
If you have received this email in error, please notify the system manager or
the sender immediately and do
not disclose the contents to anyone or make copies thereof.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] sata_fsl: Split hard and soft reset
On Nov 5, 2009, at 9:02 AM, Kumar Gala wrote: On Oct 16, 2009, at 11:44 AM, Anton Vorontsov wrote: From: Jiang Yutang b14...@freescale.com Split sata_fsl_softreset() into hard and soft resets to make error-handling more efficient device and PMP detection more reliable. Also includes fix for PMP support, driver tested with Sil3726, Sil4726 Exar PMP controllers. [AV: Also fixes resuming from deep sleep on MPC8315 CPUs] Signed-off-by: Jiang Yutang b14...@freescale.com Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- drivers/ata/sata_fsl.c | 84 +--- 1 files changed, 44 insertions(+), 40 deletions(-) Jeff, any update on this going in for .32? Jeff? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map
On Nov 17, 2009, at 1:10 AM, Li Yang wrote: Rather than the original intelligent way, we grant user more freedom. This enables user to map cacheable memory not managed by Linux. Signed-off-by: Li Yang le...@freescale.com --- The only direct users of this function is fb_mmap() and /dev/mem mmap. Although I'm not sure if anything is depending on the intelligent setting of cacheability. is there some reason to change this? - k arch/powerpc/mm/mem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 579382c..0fd267e 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -101,7 +101,7 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn, if (ppc_md.phys_mem_access_prot) return ppc_md.phys_mem_access_prot(file, pfn, size, vma_prot); - if (!page_is_ram(pfn)) + if (file-f_flags O_SYNC) vma_prot = pgprot_noncached(vma_prot); return vma_prot; -- 1.6.4 ___ 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
Re: [PATCH] sata_fsl: Split hard and soft reset
On Nov 19, 2009, at 7:51 AM, Kumar Gala wrote: On Nov 5, 2009, at 9:02 AM, Kumar Gala wrote: On Oct 16, 2009, at 11:44 AM, Anton Vorontsov wrote: From: Jiang Yutang b14...@freescale.com Split sata_fsl_softreset() into hard and soft resets to make error-handling more efficient device and PMP detection more reliable. Also includes fix for PMP support, driver tested with Sil3726, Sil4726 Exar PMP controllers. [AV: Also fixes resuming from deep sleep on MPC8315 CPUs] Signed-off-by: Jiang Yutang b14...@freescale.com Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- drivers/ata/sata_fsl.c | 84 +--- 1 files changed, 44 insertions(+), 40 deletions(-) Jeff, any update on this going in for .32? Jeff? slightly ignore me, for some reason I didn't see your reply. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Bug in drivers/serial/of_serial.c?
On Thursday 19 November 2009, Alon Ziv wrote:
On Thursday, November 19, 2009, Arnd Bergmann wrote:
I'd still add support for the compatible=ns16550a property
so that we do the right thing for future systems.
OK...
---
Xilinx 16550 UART is actually 16550A-compatible
Signed-off-by: Alon Ziv al...@discretix.com
Acked-by: Arnd Bergmann a...@arndb.de
Does this go through the powerpc or the tty tree?
I'd be happy if either Ben or Greg could pick this up.
I'm happy to keep maintaining the driver itself but it
would be nice to know a definite subsystem maintainer
responsible for it.
Greg, if you want to take patches for of_serial.c generally,
I'll start forwarding them to you as they come in and make
sure they apply to your tree.
Arnd
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 02406ba..241be77 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
of_device *ofdev)
static struct of_device_id __devinitdata of_platform_serial_table[] = {
{ .type = serial, .compatible = ns8250, .data = (void
*)PORT_8250, },
{ .type = serial, .compatible = ns16450, .data = (void
*)PORT_16450, },
+ { .type = serial, .compatible = xlnx,xps-uart16550-2.00.b,
.data = (void *)PORT_16550A, },
{ .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550, },
+ { .type = serial, .compatible = ns16550a, .data = (void
*)PORT_16550A, },
{ .type = serial, .compatible = ns16750, .data = (void
*)PORT_16750, },
{ .type = serial, .compatible = ns16850, .data = (void
*)PORT_16850, },
#ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
On Oct 21, 2009, at 7:50 AM, Vivek Mahajan wrote:
This adds QorIQ based Cache-SRAM support as under:-
* A small abstraction over powerpc's remote heap allocator
* Exports mpc85xx_cache_sram_alloc()/free() APIs
* Supports only one contiguous SRAM window
* Defines FSL_85XX_CACHE_SRAM and its base address
Signed-off-by: Vivek Mahajan vivek.maha...@freescale.com
---
v2: mbar(1) - eieio() as per Kumar G.
v3: Fixed cache-sram ways computation
arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 48 ++
arch/powerpc/platforms/85xx/Kconfig|9 ++
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h | 95
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 141 +++
+++
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 184 +++
+
6 files changed, 478 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsl_85xx_cache_sram.h
create mode 100644 arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
create mode 100644 arch/powerpc/sysdev/fsl_85xx_cache_sram.c
create mode 100644 arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h b/arch/
powerpc/include/asm/fsl_85xx_cache_sram.h
new file mode 100644
index 000..2af2bdc
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * Cache SRAM handling for QorIQ platform
should say PQ3 some QorIQ platforms
+ *
+ * Author: Vivek Mahajan vivek.maha...@freescale.com
+
+ * This file is derived from the original work done
+ * by Sylvain Munaut for the Bestcomm SRAM allocator.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
+#define __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
+
+#include asm/rheap.h
+#include linux/spinlock.h
+
+/*
+ * Cache-SRAM
+ */
+
+struct mpc85xx_cache_sram {
+ phys_addr_t base_phys;
+ void *base_virt;
+ unsigned int size;
+ rh_info_t *rh;
+ spinlock_t lock;
+};
+
+extern void mpc85xx_cache_sram_free(void *ptr);
+extern void *mpc85xx_cache_sram_alloc(unsigned int size,
+ phys_addr_t *phys, unsigned int align);
+
+#endif /* __AMS_POWERPC_FSL_85XX_CACHE_SRAM_H__ */
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/
platforms/85xx/Kconfig
index d3a975e..b6f23c3 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -144,6 +144,15 @@ config SBC8560
help
This option enables support for the Wind River SBC8560 board
+config FSL_85XX_CACHE_SRAM
+ bool
+ select PPC_LIB_RHEAP
+
+config FSL_85XX_CACHE_SRAM_BASE
+ hex
+ depends on FSL_85XX_CACHE_SRAM
+ default 0xfff0
+
I really don't like setting the physical address this way, can we not
do this via the device tree?
endif # MPC85xx
config TQM85xx
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/
Makefile
index 9d4b174..745994c 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o
+obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o
fsl_85xx_cache_sram.o
obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h b/arch/
powerpc/sysdev/fsl_85xx_cache_ctlr.h
new file mode 100644
index 000..8c4a4ac
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
@@ -0,0 +1,95 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc
+ *
+ * QorIQ based Cache Controller Memory Mapped Registers
PQ3 or some QorIQ
+ *
+ * Author: Vivek Mahajan vivek.maha...@freescale.com
+ *
+ * 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.
+ *
+ * This program is
Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
On Nov 19, 2009, at 8:21 AM, Kumar Gala wrote:
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/
platforms/85xx/Kconfig
index d3a975e..b6f23c3 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -144,6 +144,15 @@ config SBC8560
help
This option enables support for the Wind River SBC8560 board
+config FSL_85XX_CACHE_SRAM
+ bool
+ select PPC_LIB_RHEAP
+
+config FSL_85XX_CACHE_SRAM_BASE
+ hex
+ depends on FSL_85XX_CACHE_SRAM
+ default 0xfff0
+
I really don't like setting the physical address this way, can we
not do this via the device tree?
At a high level I think we should add something like the following in
the .dts:
s...@fff0 {
fsl,sram-ctrl-handle = L2;
reg = 0xfff0 0x;
compatible = fsl,mpc85xx-l2-sram;
}
the can be the size the sram is configured as.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull 'next' branch of 4xx tree
On Wed, Nov 04, 2009 at 01:55:19PM -0500, Josh Boyer wrote: Hi Ben, Please pull the next branch of the 4xx tree to get the following commits. I have some other things in the middle of being worked that may or may not make it in time for the next release, so I wanted to get these commits into your tree now rather than wait. Erm... ping? I see you've updated your next branch but not pulled this still... josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull 'next' branch of 4xx tree
On Nov 19, 2009, at 8:45 AM, Josh Boyer wrote: On Wed, Nov 04, 2009 at 01:55:19PM -0500, Josh Boyer wrote: Hi Ben, Please pull the next branch of the 4xx tree to get the following commits. I have some other things in the middle of being worked that may or may not make it in time for the next release, so I wanted to get these commits into your tree now rather than wait. Erm... ping? I see you've updated your next branch but not pulled this still... Also my next branch. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
tg3: link is permanently down after ifdown and ifup
Hi, I have a problem with tg3 driver on a custom MPC8536 based board running linux-2.6.31, with tg3 and Broadcom phy drivers taken from linux-2.6.32-rc7. Broadcom NIC is BCM57760, phy is BCM57780. The problem I'm seeing is that the downing and interface leads to permanent link loss, even after interface is upped again. E.g, to reproduce the problem it is sufficient to run: modprobe tg3 ifconfig eth2 up ifconfig eth2 down ifconfig eth2 up After ifdown PHY LEDs also go down and do not come back after ifup. Ethtool reports that no link is detected. After reloading the driver the link comes back. Am I the only one seeing this problem ? Any help on fixing this is appreciated. Thanks a lot. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Bug in drivers/serial/of_serial.c?
On Thu, Nov 19, 2009 at 03:09:31PM +0100, Arnd Bergmann wrote: On Thursday 19 November 2009, Alon Ziv wrote: On Thursday, November 19, 2009, Arnd Bergmann wrote: I'd still add support for the compatible=ns16550a property so that we do the right thing for future systems. OK... --- Xilinx 16550 UART is actually 16550A-compatible Signed-off-by: Alon Ziv al...@discretix.com Acked-by: Arnd Bergmann a...@arndb.de Does this go through the powerpc or the tty tree? I'd be happy if either Ben or Greg could pick this up. I'm happy to keep maintaining the driver itself but it would be nice to know a definite subsystem maintainer responsible for it. Greg, if you want to take patches for of_serial.c generally, I'll start forwarding them to you as they come in and make sure they apply to your tree. Sure, I would be glad to do so, send them on. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: tg3: link is permanently down after ifdown and ifup
Hi, The problem goes away if I remove the call to tg3_set_power_state(tp, PCI_D3hot); from tg3_close(). Some relevant stuff from dmesg: pci 0002:05:00.0: PME# supported from D3hot D3cold pci 0002:05:00.0: PME# disabled tg3.c:v3.102 (September 1, 2009) tg3 0002:05:00.0: enabling device ( - 0002) tg3 0002:05:00.0: PME# disabled tg3 mdio bus: probed eth2: Tigon3 [partno(BCM57760) rev 57780001] (PCI Express) MAC address 00:10:18:00:00:00 eth2: attached PHY driver [Broadcom BCM57780] (mii_bus:phy_addr=500:01) eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] eth2: dma_rwctrl[7618] dma_mask[64-bit] Is my problem related to hardware or it's a tg3 driver bug ? Thanks a lot. Felix. Felix Radensky wrote: Hi, I have a problem with tg3 driver on a custom MPC8536 based board running linux-2.6.31, with tg3 and Broadcom phy drivers taken from linux-2.6.32-rc7. Broadcom NIC is BCM57760, phy is BCM57780. The problem I'm seeing is that the downing and interface leads to permanent link loss, even after interface is upped again. E.g, to reproduce the problem it is sufficient to run: modprobe tg3 ifconfig eth2 up ifconfig eth2 down ifconfig eth2 up After ifdown PHY LEDs also go down and do not come back after ifup. Ethtool reports that no link is detected. After reloading the driver the link comes back. Am I the only one seeing this problem ? Any help on fixing this is appreciated. Thanks a lot. Felix. ___ 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
RE: Bug in drivers/serial/of_serial.c?
-Original Message-
From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Alon
Ziv
Sent: Thursday, November 19, 2009 4:47 AM
To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
Subject: RE: Bug in drivers/serial/of_serial.c?
Hi,
On Monday, November 16, 2009, Arnd wrote:
- { .type = serial, .compatible = ns16550, .data =
(void
*)PORT_16550, },
+ { .type = serial, .compatible = ns16550, .data =
(void
*)PORT_16550A, },
Does not seem logical. If the device claims compatibility with
ns16550, we should
not automatically assume it's an ns16550a. Why not add another line
for
Unfortunately, there is no way to change what the device claims--it's
encoded into the OpenFirmware tree by the EDK tools.
And, in any case, the device is actually not lying: it _is_ compatible
with NS16550--just with a non-buggy one. Unfortunately the kernel
driver for 8250-class UARTs makes the conservative choice to assume
any
16550 is one of the (early, buggy) revisions where the FIFO was
non-functional; any 16550 with working UART is classed as a 16550A.
Definitely changing what is generated by EDK seems to make sense here...
Steve
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Bug in drivers/serial/of_serial.c?
NAK.
If the problem is in the device trees that are being generated, we
should fix the issue there.
We've been trying to avoid putting the fully specified IP versions in
the kernel like this, since
the IP changes so often.
Steve
-Original Message-
From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Alon
Ziv
Sent: Thursday, November 19, 2009 5:49 AM
To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
Subject: RE: Bug in drivers/serial/of_serial.c?
On Thursday, November 19, 2009, Arnd Bergmann wrote:
I'd still add support for the compatible=ns16550a property
so that we do the right thing for future systems.
OK...
---
Xilinx 16550 UART is actually 16550A-compatible
Signed-off-by: Alon Ziv al...@discretix.com
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 02406ba..241be77 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
of_device *ofdev)
static struct of_device_id __devinitdata of_platform_serial_table[] =
{
{ .type = serial, .compatible = ns8250, .data = (void
*)PORT_8250, },
{ .type = serial, .compatible = ns16450, .data = (void
*)PORT_16450, },
+ { .type = serial, .compatible = xlnx,xps-uart16550-2.00.b,
.data = (void *)PORT_16550A, },
{ .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550, },
+ { .type = serial, .compatible = ns16550a, .data = (void
*)PORT_16550A, },
{ .type = serial, .compatible = ns16750, .data = (void
*)PORT_16750, },
{ .type = serial, .compatible = ns16850, .data = (void
*)PORT_16850, },
#ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
**
IMPORTANT: The contents of this email and any attachments are
confidential. They are intended for the
named recipient(s) only.
If you have received this email in error, please notify the system
manager or the sender immediately
and do
not disclose the contents to anyone or make copies thereof.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Bug in drivers/serial/of_serial.c?
On Thursday 19 November 2009, Stephen Neuendorffer wrote: If the problem is in the device trees that are being generated, we should fix the issue there. We've been trying to avoid putting the fully specified IP versions in the kernel like this, since the IP changes so often. No, the problem that Alon has is that the firmware currently has no way whatsoever to give a correct device tree, because of-serial.c does not even know about ns16550a. The patch adds both a special-case for the specific uart he is using so that one is grandfathered in and a new compatible value so future boards can specify both ns16550a and ns16550. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: watchdog exception on 8548CDS during cpu_idle
On Wed, Nov 18, 2009 at 03:53:27PM -0800, Ming Lei wrote: I used the vanilla linux 2.6.30 and compiled with mpc85xx_defconfig(enable CONFIG_BOOK_WDT) and then ran on 8548CDS and soon after I saw the prompt I hit this watchdog. bash-2.04# PowerPC Book-E Watchdog Exception NIP: c000b740 LR: c00088dc CTR: c000b6b0 REGS: cfffbf10 TRAP: 3202 Not tainted (2.6.30) MSR: 00029000 EE,ME,CE CR: 28028048 XER: 2000 TASK = c04f4458[0] 'swapper' THREAD: c052c000 GPR00: c000b6b0 c052df90 c04f4458 0080 80804080 001d c053af48 00069000 GPR08: 08954400 002167ee 7f652f31 0ffad800 0fff GPR16: f30a620b 0ff50450 GPR24: c053506c c0534fa0 c0534fa0 c052c034 0008 c052c000 NIP [c000b740] e500_idle+0x90/0x94 LR [c00088dc] cpu_idle+0x98/0xec Call Trace: [c052df90] [c000889c] cpu_idle+0x58/0xec (unreliable) [c052dfb0] [c00023ec] rest_init+0x5c/0x70 [c052dfc0] [c04c16f4] start_kernel+0x22c/0x290 [c052dff0] [c398] skpinv+0x2b0/0x2ec Instruction dump: 7c90faa6 548402ce 7c841b78 4c00012c 7c90fba6 4c00012c 7ce000a6 64e70004 60e78000 7c0004ac 7ce00124 4c00012c 4800 812b00a0 912b0090 3960 Have anyone seen this before? Why the EE bit is on in the stack trace? I put show_regs in watchdog exception handler in traps.c. I verified that EE is off when entering the watchdog exception handler. Can I trust this stack trace? EE is there because it was set in the context that got interrupted, just as all the other state is for the interrupted context. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Bug in drivers/serial/of_serial.c?
-Original Message- From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org [mailto:linuxppc-dev- bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Arnd Bergmann Sent: Thursday, November 19, 2009 9:33 AM To: Stephen Neuendorffer Cc: John Linn; Alon Ziv; linuxppc-dev@lists.ozlabs.org Subject: Re: Bug in drivers/serial/of_serial.c? On Thursday 19 November 2009, Stephen Neuendorffer wrote: If the problem is in the device trees that are being generated, we should fix the issue there. We've been trying to avoid putting the fully specified IP versions in the kernel like this, since the IP changes so often. No, the problem that Alon has is that the firmware currently has no way whatsoever to give a correct device tree, because of-serial.c does not even know about ns16550a. The patch adds both a special-case for the specific uart he is using so that one is grandfathered in and a new compatible value so future boards can specify both ns16550a and ns16550. That's true... The 16550a line still needs to get added, but not the xlnx- specific line. Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
On Thu, Nov 19, 2009 at 08:29:19AM -0600, Kumar Gala wrote:
+config FSL_85XX_CACHE_SRAM_BASE
+ hex
+ depends on FSL_85XX_CACHE_SRAM
+ default 0xfff0
+
I really don't like setting the physical address this way, can we
not do this via the device tree?
At a high level I think we should add something like the following in
the .dts:
s...@fff0 {
fsl,sram-ctrl-handle = L2;
reg = 0xfff0 0x;
compatible = fsl,mpc85xx-l2-sram;
}
the can be the size the sram is configured as.
I don't see why this needs to go in the device tree, if it's the kernel
that is setting it up. The kernel can pick any address and size it
wants.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH/RFC] Booting Xilinx ML510 board using SystemACE
-Original Message- From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org [mailto:linuxppc-dev- bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Alon Ziv Sent: Thursday, November 19, 2009 4:57 AM To: Stephen Neuendorffer; linuxppc-dev Cc: John Linn Subject: RE: [PATCH/RFC] Booting Xilinx ML510 board using SystemACE Hi, On Monday, November 16, 2009, Stephen wrote: There are at least two other ways that you might be able to reset a board: 1) Internally through the ICAP device. 2) Through a GPIO connected externally to the reset logic. Unfortunately none of these is relevant for the specific board in question (Xilinx ML510 reference system)... Well, board != system. :) ML510 could easily include an ICAP device. Probably it would be best to have a mechanism in the device tree which references the reset mechanism? I am sorely lacking in expertise for this :(, and wouldn't even know where to begin... Is it possible at all to add custom information into the device tree? And even if yes--how will platform code bind to the reset mechanism? [...] In any event, you probably don't want a driver to eplicitly reference the plaform code. If you want to do it explicitly like this, it would better to have the plaform code reference the driver mechanism. I don't see how this can be done: if the driver is to publish some driver_reset_system function to the platform code, it needs _some_ mechanism for telling this fact to the system... Think of it this way: The driver is usable on many more platforms than just the one you've modified. Your addition of the hook into the platform code requires that that hook always be there. It would be much better to provide a configuration-based way of allowing the platform code to make use of the sysace reset, if it desires. And such a mechanism won't look all that different from my callback, IMO (except it may be slightly prettied up). The callback isn't the problem, it's how the callback gets registered with the platform code/device tree. Of course, one obvious thing that must be done is move this code out of arch/powerpc/platforms/44x/virtex.c and into (e.g.) arch/powerpc/kernel/setup-common.c, and add some set_machine_restart_function wrapper to access it more cleanly (also defining this function as a null function when inapplicable). If this satisfies your standards, I can easily post an updated patch :) The driver isn't even powerpc specific, it could also be used on the microblaze, and I think you'll find alot of resistance to adding that kind of hook to an architecture that has just spent a bunch of time getting rid of alot of direct binding between platform code and drivers. Grant, do you have a comment here? Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Bug in drivers/serial/of_serial.c?
NAK also.
Yes we can generate a different device tree to fix this issue.
Thanks,
John
-Original Message-
From: Stephen Neuendorffer
Sent: Thursday, November 19, 2009 10:23 AM
To: Alon Ziv; Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
Cc: John Linn; grant.lik...@secretlab.ca
Subject: RE: Bug in drivers/serial/of_serial.c?
NAK.
If the problem is in the device trees that are being generated, we
should fix the issue there.
We've been trying to avoid putting the fully specified IP versions in
the kernel like this, since
the IP changes so often.
Steve
-Original Message-
From:
linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of
Alon Ziv
Sent: Thursday, November 19, 2009 5:49 AM
To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
Subject: RE: Bug in drivers/serial/of_serial.c?
On Thursday, November 19, 2009, Arnd Bergmann wrote:
I'd still add support for the compatible=ns16550a property
so that we do the right thing for future systems.
OK...
---
Xilinx 16550 UART is actually 16550A-compatible
Signed-off-by: Alon Ziv al...@discretix.com
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 02406ba..241be77 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
of_device *ofdev)
static struct of_device_id __devinitdata of_platform_serial_table[]
= {
{ .type = serial, .compatible = ns8250, .data = (void
*)PORT_8250, },
{ .type = serial, .compatible = ns16450, .data = (void
*)PORT_16450, },
+ { .type = serial, .compatible = xlnx,xps-uart16550-2.00.b,
.data = (void *)PORT_16550A, },
{ .type = serial, .compatible = ns16550, .data = (void
*)PORT_16550, },
+ { .type = serial, .compatible = ns16550a, .data = (void
*)PORT_16550A, },
{ .type = serial, .compatible = ns16750, .data = (void
*)PORT_16750, },
{ .type = serial, .compatible = ns16850, .data = (void
*)PORT_16850, },
#ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
**
IMPORTANT: The contents of this email and any attachments are
confidential. They are intended for
the
named recipient(s) only.
If you have received this email in error, please notify the system
manager or the sender
immediately
and do
not disclose the contents to anyone or make copies thereof.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
On Nov 19, 2009, at 11:45 AM, Scott Wood wrote:
On Thu, Nov 19, 2009 at 08:29:19AM -0600, Kumar Gala wrote:
+config FSL_85XX_CACHE_SRAM_BASE
+ hex
+ depends on FSL_85XX_CACHE_SRAM
+ default 0xfff0
+
I really don't like setting the physical address this way, can we
not do this via the device tree?
At a high level I think we should add something like the following in
the .dts:
s...@fff0 {
fsl,sram-ctrl-handle = L2;
reg = 0xfff0 0x;
compatible = fsl,mpc85xx-l2-sram;
}
the can be the size the sram is configured as.
I don't see why this needs to go in the device tree, if it's the
kernel
that is setting it up. The kernel can pick any address and size it
wants.
It can, we just don't normally do physical address allocation in the
kernel. I just dont want it as a compile time thing. Either .dts or
make it runtime allocated by the kernel.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ppc64: re-enable kexec to allow module loads with CONFIG_MODVERSIONS and CONFIG_RELOCATABLE turned on
Hey there-
Before anyone flames me for what a oddball solution this is, let me just
say I'm trying to get the ball rolling here. I think there may be better
solutions that can be impemented in reloc_64.S, but I've yet to make any of the
ones I've tried work successfully. I'm open to suggestions, but this solution
is the only one so far that I've been able to get to work. thanks :)
Adjust crcs in __kcrctab_* sections if relocs are used with CONFIG_RELOCATABLE
When CONFIG_MODVERSIONS and CONFIG_RELOCATABLE are enabled on powerpc platforms,
kdump has been failing in a rather odd way. specifically modules will not
install. This is because when validating the crcs of symbols that the module
needs, the crc of the module never matches the crc that is stored in the kernel.
The underlying cause of this is how CONFIG_MODVERSIONS is implemented, and how
CONFIG_RELOCATABLE are implemented. with CONFIG_MODVERSIONS enabled, for every
exported symbol in the kernel we emit 2 symbols, __crc_#sym which is declared
extern and __kcrctab_##sym, which is placed in the __kcrctab section of the
binary. The latter has its value set equal to the address of the former
(recalling it is declared extern). After the object file is built, genksyms is
run on the processed source, and crcs are computed for each exported symbol.
genksyms then emits a linker script which defines each of the needed __crc_##sym
symbols, and sets their addresses euqal to their respective crcs. This script
is then used in a secondary link to the previously build object file, so that
the crcs of the missing symbol can be validated on module insert.
The problem here is that because __kcrctab_sym is set equal to __crc_##sym, a
relocation entry is emitted by the compiler for the __kcrctab__##sym. Normally
this is not a problem, since relocation on other arches is done without the aid
of .rel.dyn sections. PPC however uses these relocations when
CONFIG_RELOCATABLE is enabled. nominally, since addressing starts at 0 for ppc,
its irrelevant, but if we start at a non-zero address (like we do when booting
via kexec from reserved crashkernel memory), the ppc boot code iterates over the
relocation entries, and winds up adding that relocation offset to all symbols,
including the symbols that are actually the aforementioned crc values in the
__kcrctab_* sections. This effectively corrupts the crcs and prevents any
module loads from happening during a kdump.
My solution is to 'undo' these relocations prior to boot up. If
ARCH_USES_RELOC_ENTRIES is defined, we add a symbol at address zero to the
linker script for that arch (I call it reloc_start, so that reloc_start = 0).
This symbol will then indicate the relocation offset for any given boot. We
also add an initcall to the module code that, during boot, scans the __kcrctab_*
sections and subtracts reloc_start from every entry in those sections,
restoring the appropriate crc value.
I've verified that this allows kexec to work properly on ppc64 systems myself.
Signed-off-by: Neil Horman nhor...@tuxdriver.com
arch/powerpc/include/asm/local.h |6 ++
arch/powerpc/kernel/vmlinux.lds.S |4
kernel/module.c | 30 ++
3 files changed, 40 insertions(+)
diff --git a/arch/powerpc/include/asm/local.h b/arch/powerpc/include/asm/local.h
index 84b457a..9cc49e5 100644
--- a/arch/powerpc/include/asm/local.h
+++ b/arch/powerpc/include/asm/local.h
@@ -4,6 +4,12 @@
#include linux/percpu.h
#include asm/atomic.h
+#ifdef CONFIG_MODVERSIONS
+#define ARCH_USES_RELOC_ENTRIES
+
+extern unsigned long reloc_start;
+#endif
+
typedef struct
{
atomic_long_t a;
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index 27735a7..2b9fb2e 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -38,6 +38,10 @@ jiffies = jiffies_64 + 4;
#endif
SECTIONS
{
+ . = 0;
+ reloc_start = .;
+ . = 0;
+
. = KERNELBASE;
/*
diff --git a/kernel/module.c b/kernel/module.c
index 8b7d880..87a4928 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -181,8 +181,11 @@ extern const struct kernel_symbol
__stop___ksymtab_gpl_future[];
extern const struct kernel_symbol __start___ksymtab_gpl_future[];
extern const struct kernel_symbol __stop___ksymtab_gpl_future[];
extern const unsigned long __start___kcrctab[];
+extern const unsigned long __stop___kcrctab[];
extern const unsigned long __start___kcrctab_gpl[];
+extern const unsigned long __stop___kcrctab_gpl[];
extern const unsigned long __start___kcrctab_gpl_future[];
+extern const unsigned long __stop___kcrctab_gpl_future[];
#ifdef CONFIG_UNUSED_SYMBOLS
extern const struct kernel_symbol __start___ksymtab_unused[];
extern const struct kernel_symbol __stop___ksymtab_unused[];
@@ -3144,3 +3147,30 @@ int module_get_iter_tracepoints(struct tracepoint_iter
*iter)
return found;
}
#endif
+
+#ifdef
Re: [patch] powerpc: Fixup last users of irq_chip-typename - V2
On 11/19/2009 01:44 AM, Thomas Gleixner wrote:
The typename member of struct irq_chip was kept for migration purposes
and is obsolete since more than 2 years. Fix up the leftovers.
Index: linux-2.6-tip/arch/powerpc/platforms/ps3/interrupt.c
===
--- linux-2.6-tip.orig/arch/powerpc/platforms/ps3/interrupt.c
+++ linux-2.6-tip/arch/powerpc/platforms/ps3/interrupt.c
@@ -152,7 +152,7 @@ static void ps3_chip_eoi(unsigned int vi
*/
static struct irq_chip ps3_irq_chip = {
- .typename = ps3,
+ .name = ps3,
.mask = ps3_chip_mask,
.unmask = ps3_chip_unmask,
.eoi = ps3_chip_eoi,
This PS3 part looks OK.
Acked-by: Geoff Levand geoffrey.lev...@am.sony.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: tg3: link is permanently down after ifdown and ifup
On Thu, 2009-11-19 at 08:08 -0800, Felix Radensky wrote: Hi, The problem goes away if I remove the call to tg3_set_power_state(tp, PCI_D3hot); from tg3_close(). Added Matt to CC. He is on vacation and may not be able to look into this right away. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] sata_fsl: Split hard and soft reset
On 10/16/2009 12:44 PM, Anton Vorontsov wrote: From: Jiang Yutangb14...@freescale.com Split sata_fsl_softreset() into hard and soft resets to make error-handling more efficient device and PMP detection more reliable. Also includes fix for PMP support, driver tested with Sil3726, Sil4726 Exar PMP controllers. [AV: Also fixes resuming from deep sleep on MPC8315 CPUs] Signed-off-by: Jiang Yutangb14...@freescale.com Signed-off-by: Anton Vorontsovavoront...@ru.mvista.com --- drivers/ata/sata_fsl.c | 84 +--- 1 files changed, 44 insertions(+), 40 deletions(-) applied #upstream-fixes ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v3] Add asynchronous notification support
On 07/01/2009 11:29 AM, ashish kalra wrote: Enable device hot-plug support on Port multiplier fan-out ports v3 fixes whitespace/identation issues Signed-off-by: Ashish Kalra ashish.ka...@freescale.com --- drivers/ata/sata_fsl.c | 15 ++- 1 files changed, 10 insertions(+), 5 deletions(-) applied #upstream ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch 3/3] [v2] powerpc: make the CMM memory hotplug aware
On Wed, 18 Nov 2009 12:59:08 -0600
Robert Jennings r...@linux.vnet.ibm.com wrote:
The Collaborative Memory Manager (CMM) module allocates individual pages
over time that are not migratable. On a long running system this can
severely impact the ability to find enough pages to support a hotplug
memory remove operation.
This patch adds a memory isolation notifier and a memory hotplug notifier.
The memory isolation notifier will return the number of pages found
in the range specified. This is used to determine if all of the used
pages in a pageblock are owned by the balloon (or other entities in
the notifier chain). The hotplug notifier will free pages in the range
which is to be removed. The priority of this hotplug notifier is low
so that it will be called near last, this helps avoids removing loaned
pages in operations that fail due to other handlers.
CMM activity will be halted when hotplug remove operations are active
and resume activity after a delay period to allow the hypervisor time
to adjust.
Signed-off-by: Robert Jennings r...@linux.vnet.ibm.com
Cc: Mel Gorman m...@csn.ul.ie
Cc: Ingo Molnar mi...@elte.hu
Cc: Brian King brk...@linux.vnet.ibm.com
Cc: Paul Mackerras pau...@samba.org
Cc: Martin Schwidefsky schwidef...@de.ibm.com
Cc: Gerald Schaefer gera...@linux.vnet.ibm.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Andrew Morton a...@linux-foundation.org
---
The pages used to track loaned pages should not be marked as MOVABLE, so
they need to be handled during a memory offline event.
Changes:
* The structures for recording loaned pages are not allocated as MOVABLE
* The structures for recording loaned pages are removed from sections
being taken offline by moving their contents to a newly allocated page.
arch/powerpc/platforms/pseries/cmm.c | 254
++-
1 file changed, 248 insertions(+), 6 deletions(-)
Incremental patch is:
: ---
a/arch/powerpc/platforms/pseries/cmm.c~powerpc-make-the-cmm-memory-hotplug-aware-update
: +++ a/arch/powerpc/platforms/pseries/cmm.c
: @@ -148,8 +148,7 @@ static long cmm_alloc_pages(long nr)
: spin_unlock(cmm_lock);
: npa = (struct cmm_page_array *)__get_free_page(
: GFP_NOIO | __GFP_NOWARN |
: - __GFP_NORETRY | __GFP_NOMEMALLOC |
: - __GFP_MOVABLE);
: + __GFP_NORETRY | __GFP_NOMEMALLOC);
: if (!npa) {
: pr_info(%s: Can not allocate new page list\n,
__func__);
: free_page(addr);
: @@ -480,6 +479,8 @@ static unsigned long cmm_count_pages(voi
: spin_lock(cmm_lock);
: pa = cmm_page_list;
: while (pa) {
: + if ((unsigned long)pa = start (unsigned long)pa end)
: + marg-pages_found++;
: for (idx = 0; idx pa-index; idx++)
: if (pa-page[idx] = start pa-page[idx] end)
: marg-pages_found++;
: @@ -531,7 +532,7 @@ static int cmm_mem_going_offline(void *a
: struct memory_notify *marg = arg;
: unsigned long start_page = (unsigned long)pfn_to_kaddr(marg-start_pfn);
: unsigned long end_page = start_page + (marg-nr_pages PAGE_SHIFT);
: - struct cmm_page_array *pa_curr, *pa_last;
: + struct cmm_page_array *pa_curr, *pa_last, *npa;
: unsigned long idx;
: unsigned long freed = 0;
:
: @@ -539,6 +540,7 @@ static int cmm_mem_going_offline(void *a
: start_page, marg-nr_pages);
: spin_lock(cmm_lock);
:
: + /* Search the page list for pages in the range to be offlined */
: pa_last = pa_curr = cmm_page_list;
: while (pa_curr) {
: for (idx = (pa_curr-index - 1); (idx + 1) 0; idx--) {
: @@ -563,6 +565,37 @@ static int cmm_mem_going_offline(void *a
: }
: pa_curr = pa_curr-next;
: }
: +
: + /* Search for page list structures in the range to be offlined */
: + pa_last = NULL;
: + pa_curr = cmm_page_list;
: + while (pa_curr) {
: + if (((unsigned long)pa_curr = start_page)
: + ((unsigned long)pa_curr end_page)) {
: + npa = (struct cmm_page_array *)__get_free_page(
: + GFP_NOIO | __GFP_NOWARN |
: + __GFP_NORETRY | __GFP_NOMEMALLOC);
: + if (!npa) {
: + spin_unlock(cmm_lock);
: + cmm_dbg(Failed to allocate memory for list
: + management. Memory hotplug
: + failed.\n);
: + return ENOMEM;
: +
[PATCH 3/4] edac: Mask mpc85xx ECC syndrome appropriately
With a 64-bit wide data bus only the lowest 8-bits of the ECC syndrome
are relevant. With a 32-bit wide data bus only the lowest 16-bits are
relevant on most architectures.
Without this change, the ECC syndrome displayed can be mildly confusing,
eg:
EDAC MPC85xx MC1: syndrome: 0x25252525
When in reality the ECC syndrome is 0x25.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
A variety of Freescale manual's say a variety of different things about
how to decode the CAPTURE_ECC (syndrome) register. I don't have a
system with a 32-bit bus to test on, but I believe the change is
correct. It'd be good to get an ACK from someone at Freescale
about this change though.
drivers/edac/mpc85xx_edac.c | 12 +++-
drivers/edac/mpc85xx_edac.h |3 +++
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index ecd5928..6d0114a 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -672,6 +672,7 @@ static void mpc85xx_mc_check(struct mem_ctl_info *mci)
{
struct mpc85xx_mc_pdata *pdata = mci-pvt_info;
struct csrow_info *csrow;
+ u32 bus_width;
u32 err_detect;
u32 syndrome;
u32 err_addr;
@@ -692,6 +693,15 @@ static void mpc85xx_mc_check(struct mem_ctl_info *mci)
}
syndrome = in_be32(pdata-mc_vbase + MPC85XX_MC_CAPTURE_ECC);
+
+ /* Mask off appropriate bits of syndrome based on bus width */
+ bus_width = (in_be32(pdata-mc_vbase + MPC85XX_MC_DDR_SDRAM_CFG)
+ DSC_DBW_MASK) ? 32 : 64;
+ if (bus_width == 64)
+ syndrome = 0xff;
+ else
+ syndrome = 0x;
+
err_addr = in_be32(pdata-mc_vbase + MPC85XX_MC_CAPTURE_ADDRESS);
pfn = err_addr PAGE_SHIFT;
@@ -707,7 +717,7 @@ static void mpc85xx_mc_check(struct mem_ctl_info *mci)
mpc85xx_mc_printk(mci, KERN_ERR, Capture Data Low: %#8.8x\n,
in_be32(pdata-mc_vbase +
MPC85XX_MC_CAPTURE_DATA_LO));
- mpc85xx_mc_printk(mci, KERN_ERR, syndrome: %#8.8x\n, syndrome);
+ mpc85xx_mc_printk(mci, KERN_ERR, syndrome: %#2.2x\n, syndrome);
mpc85xx_mc_printk(mci, KERN_ERR, err addr: %#8.8x\n, err_addr);
mpc85xx_mc_printk(mci, KERN_ERR, PFN: %#8.8x\n, pfn);
diff --git a/drivers/edac/mpc85xx_edac.h b/drivers/edac/mpc85xx_edac.h
index 52432ee..cb24df8 100644
--- a/drivers/edac/mpc85xx_edac.h
+++ b/drivers/edac/mpc85xx_edac.h
@@ -48,6 +48,9 @@
#define DSC_MEM_EN 0x8000
#define DSC_ECC_EN 0x2000
#define DSC_RD_EN 0x1000
+#define DSC_DBW_MASK 0x0018
+#define DSC_DBW_32 0x0008
+#define DSC_DBW_64 0x
#define DSC_SDTYPE_MASK0x0700
--
1.6.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] edac: Fix mpc85xx page calculation
Commit b4846251727a38a7f248e41308c060995371dd05 accidentally broke how a chip select's first and last page addresses are calculated. The page addresses are being shifted too far right by PAGE_SHIFT. This results in errors such as: EDAC MPC85xx MC1: Err addr: 0x003075c0 EDAC MPC85xx MC1: PFN: 0x0307 EDAC MPC85xx MC1: PFN out of range! EDAC MC1: INTERNAL ERROR: row out of range (4 = 4) EDAC MC1: CE - no information available: INTERNAL ERROR The vale of PAGE_SHIFT is already being taken into consideration during the calculation of the 'start' and 'end' variables, thus it is not necessary to account for it again when setting a chip select's first and last page address. Signed-off-by: Peter Tyser pty...@xes-inc.com --- drivers/edac/mpc85xx_edac.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c index 28d3211..ecd5928 100644 --- a/drivers/edac/mpc85xx_edac.c +++ b/drivers/edac/mpc85xx_edac.c @@ -804,8 +804,8 @@ static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci) end = (24 - PAGE_SHIFT); end|= (1 (24 - PAGE_SHIFT)) - 1; - csrow-first_page = start PAGE_SHIFT; - csrow-last_page = end PAGE_SHIFT; + csrow-first_page = start; + csrow-last_page = end; csrow-nr_pages = end + 1 - start; csrow-grain = 8; csrow-mtype = mtype; -- 1.6.2.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] edac: Improve SDRAM error reporting for mpc85xx
Add the ability to detect the specific data line or ECC line which
failed when printing out SDRAM single-bit errors. An example of a
single-bit SDRAM ECC error is below:
EDAC MPC85xx MC1: Err Detect Register: 0x8004
EDAC MPC85xx MC1: Faulty data bit: 59
EDAC MPC85xx MC1: Expected Data / ECC: 0x7f80d000_409effa0 / 0x6d
EDAC MPC85xx MC1: Captured Data / ECC: 0x7780d000_409effa0 / 0x6d
EDAC MPC85xx MC1: Err addr: 0x00031ca0
EDAC MPC85xx MC1: PFN: 0x0031
Knowning which specific data or ECC line caused an error can be useful in
tracking down hardware issues such as improperly terminated signals,
loose pins, etc.
Note that this feature is only currently enabled for 64-bit wide data
buses, 32-bit wide bus support should be added.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
I don't have any 32-bit wide systems to test on. If someone has one
and is willing to give this patch a shot with the check for a 64-bit
data bus removed it would be much appreciated and I can re-submit
with both 32 and 64 bit buses supported.
drivers/edac/mpc85xx_edac.c | 146 ---
1 files changed, 138 insertions(+), 8 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 6d0114a..517042f 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -668,6 +668,111 @@ static struct of_platform_driver mpc85xx_l2_err_driver = {
/ MC Err device ***/
+/*
+ * Taken from table 8-55 in the MPC8641 User's Manual and/or 9-61 in the
+ * MPC8572 User's Manual. Each line represents a syndrome bit column as a
+ * 64-bit value, but split into an upper and lower 32-bit chunk. The labels
+ * below correspond to Freescale's manuals.
+ */
+static unsigned int ecc_table[16] = {
+ /* MSB LSB */
+ /* [0:31][32:63] */
+ 0xf00fe11e, 0xc33c0ff7, /* Syndrome bit 7 */
+ 0x00ff00ff, 0x00fff0ff,
+ 0x0f0f0f0f, 0x0f0fff00,
+ 0x, 0x000f,
+ 0x, 0x222f,
+ 0x, 0x4441,
+ 0x, 0x8882,
+ 0x, 0x1114, /* Syndrome bit 0 */
+};
+
+/*
+ * Calculate the correct ECC value for a 64-bit value specified by high:low
+ */
+static u8 calculate_ecc(u32 high, u32 low)
+{
+ u32 mask_low;
+ u32 mask_high;
+ int bit_cnt;
+ u8 ecc = 0;
+ int i;
+ int j;
+
+ for (i = 0; i 8; i++) {
+ mask_high = ecc_table[i * 2];
+ mask_low = ecc_table[i * 2 + 1];
+ bit_cnt = 0;
+
+ for (j = 0; j 32; j++) {
+ if ((mask_high j) 1)
+ bit_cnt ^= (high j) 1;
+ if ((mask_low j) 1)
+ bit_cnt ^= (low j) 1;
+ }
+
+ ecc |= bit_cnt i;
+ }
+
+ return ecc;
+}
+
+/*
+ * Create the syndrome code which is generated if the data line specified by
+ * 'bit' failed. Eg generate an 8-bit codes seen in Table 8-55 in the MPC8641
+ * User's Manual and 9-61 in the MPC8572 User's Manual.
+ */
+static u8 syndrome_from_bit(unsigned int bit) {
+ int i;
+ u8 syndrome = 0;
+
+ /*
+* Cycle through the upper or lower 32-bit portion of each value in
+* ecc_table depending on if 'bit' is in the upper or lower half of
+* 64-bit data.
+*/
+ for (i = bit 32; i 16; i += 2)
+ syndrome |= ((ecc_table[i] (bit % 32)) 1) (i / 2);
+
+ return syndrome;
+}
+
+/*
+ * Decode data and ecc syndrome to determine what went wrong
+ * Note: This can only decode single-bit errors
+ */
+static void sbe_ecc_decode(u32 cap_high, u32 cap_low, u32 cap_ecc,
+ int *bad_data_bit, int *bad_ecc_bit)
+{
+ int i;
+ u8 syndrome;
+
+ *bad_data_bit = -1;
+ *bad_ecc_bit = -1;
+
+ /*
+* Calculate the ECC of the captured data and XOR it with the captured
+* ECC to find an ECC syndrome value we can search for
+*/
+ syndrome = calculate_ecc(cap_high, cap_low) ^ cap_ecc;
+
+ /* Check if a data line is stuck... */
+ for (i = 0; i 64; i++) {
+ if (syndrome == syndrome_from_bit(i)) {
+ *bad_data_bit = i;
+ return;
+ }
+ }
+
+ /* If data is correct, check ECC bits for errors... */
+ for (i = 0; i 8; i++) {
+ if ((syndrome i) 0x1) {
+ *bad_ecc_bit = i;
+ return;
+ }
+ }
+}
+
static void mpc85xx_mc_check(struct mem_ctl_info *mci)
{
struct mpc85xx_mc_pdata *pdata = mci-pvt_info;
@@ -678,6 +783,10 @@ static void mpc85xx_mc_check(struct mem_ctl_info *mci)
u32 err_addr;
u32 pfn;
int row_index;
+ u32 cap_high;
+ u32 cap_low;
+ int bad_data_bit;
+
[PATCH 1/4] edac: Remove unused mpc85xx debug code
Some unused, unsupported debug code existed in the mpc85xx EDAC driver that resulted in a build failure when CONFIG_EDAC_DEBUG was defined: drivers/edac/mpc85xx_edac.c: In function 'mpc85xx_mc_err_probe': drivers/edac/mpc85xx_edac.c:1031: error: implicit declaration of function 'edac_mc_register_mcidev_debug' drivers/edac/mpc85xx_edac.c:1031: error: 'debug_attr' undeclared (first use in this function) drivers/edac/mpc85xx_edac.c:1031: error: (Each undeclared identifier is reported only once drivers/edac/mpc85xx_edac.c:1031: error: for each function it appears in.) Signed-off-by: Peter Tyser pty...@xes-inc.com --- drivers/edac/mpc85xx_edac.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c index cf27402..28d3211 100644 --- a/drivers/edac/mpc85xx_edac.c +++ b/drivers/edac/mpc85xx_edac.c @@ -892,10 +892,6 @@ static int __devinit mpc85xx_mc_err_probe(struct of_device *op, mpc85xx_init_csrows(mci); -#ifdef CONFIG_EDAC_DEBUG - edac_mc_register_mcidev_debug((struct attribute **)debug_attr); -#endif - /* store the original error disable bits */ orig_ddr_err_disable = in_be32(pdata-mc_vbase + MPC85XX_MC_ERR_DISABLE); -- 1.6.2.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC] powerpc/mm: honor O_SYNC flag for memory map
-Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] On Nov 17, 2009, at 1:10 AM, Li Yang wrote: Rather than the original intelligent way, we grant user more freedom. This enables user to map cacheable memory not managed by Linux. Signed-off-by: Li Yang le...@freescale.com --- The only direct users of this function is fb_mmap() and /dev/mem mmap. Although I'm not sure if anything is depending on the intelligent setting of cacheability. is there some reason to change this? Because there is no way to set mapped memory as cacheable if the memory is not managed by Linux kernel. While, it's not rare in real system to allocate some dedicated memory to a certain application which is not managed by kernel and then mmap'ed the memory to the application. The memory should be cacheable but we can't map it to be cacheable due to this intelligent setting. And it is a big hit to the performance. Moreover, the standard O_SYNC flag suggest that user has the control over cacheablity, but actually we had not. - Leo - k arch/powerpc/mm/mem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 579382c..0fd267e 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -101,7 +101,7 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn, if (ppc_md.phys_mem_access_prot) return ppc_md.phys_mem_access_prot(file, pfn, size, vma_prot); -if (!page_is_ram(pfn)) +if (file-f_flags O_SYNC) vma_prot = pgprot_noncached(vma_prot); return vma_prot; -- 1.6.4 ___ 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
RE: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Gala Kumar-B11780 Sent: Thursday, November 19, 2009 7:51 PM + * Cache SRAM handling for QorIQ platform should say PQ3 some QorIQ platforms Ok +config FSL_85XX_CACHE_SRAM_BASE + hex + depends on FSL_85XX_CACHE_SRAM + default 0xfff0 + I really don't like setting the physical address this way, can we not do this via the device tree? Cache-sram does not have any device tree entry since it is not a hardware as such. Putting it under chosen can be another option. I think, Scott (cc'ed) was of the opinion that since 32b base address support is missing; so there is no point in moving this address to the command line and .config should be okay for now for it. + * QorIQ based Cache Controller Memory Mapped Registers PQ3 or some QorIQ Ok + * Simple memory allocator abstraction for QorIQ (P1/P2) based Cache-SRAM PQ3 or some QorIQ Ok + + if (!param || (strict_strtoul(param, 0, val) 0)) + return -EINVAL; + we should use memparse() Ok Thanks, Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
