Re: [PATCH] kexec memory ranges dynamic allocation
2008/10/15 Simon Horman [EMAIL PROTECTED] On Tue, Oct 14, 2008 at 07:11:19PM +0400, Maxim Uvarov wrote: Hello all, As you all know it is not easy to count exact value of memory ranges from device tree on powerpc. It very depends on how dts file was written. What do you think about really dynamic allocation buffers for this buffers? Conceptually I have no objections to the change, though I would like to get some review from ppc people. (linuxppc-dev@ozlabs.org CCed) Patch is attached. This patch doesn't seem to compile for me. # powerpc64-unknown-linux-gnu-gcc --version powerpc64-unknown-linux-gnu-gcc (GCC) 4.1.1 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. #make [snip] kexec/arch/ppc64/kexec-ppc64.c:100: warning: function declaration isn't a prototype kexec/arch/ppc64/kexec-ppc64.c: In function 'realloc_memory_ranges': kexec/arch/ppc64/kexec-ppc64.c:107: warning: passing argument 1 of 'realloc' makes pointer from integer without a cast kexec/arch/ppc64/kexec-ppc64.c:107: error: too few arguments to function 'realloc' kexec/arch/ppc64/kexec-ppc64.c:102: warning: unused variable 'tmp' Sorry I edited manually formated patch before sending and lost first argument to realloc. I will resend it. -- Simon Horman VA Linux Systems Japan K.K., Sydney, Australia Satellite Office H: www.vergenet.net/~horms/ http://www.vergenet.net/%7Ehorms/ W: www.valinux.co.jp/en -- Best regards, Maxim Uvarov ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y
* Adrian Bunk [EMAIL PROTECTED] [2008-10-14 20:58:22]: On Tue, Oct 14, 2008 at 09:10:33AM -0700, Brandeburg, Jesse wrote: Brice Goglin wrote: Adrian Bunk wrote: But considering that igb is in a similar situation it would be nice if all 3 drivers would handle it the same way. Jesse, What do you think of the below patch? Seems like a much better solution. I can have Jeff Kirsher work on the equivalent patches for igb, and ixgbe today. I am not very familiar with Kconfig, but it seems to solve the problem. If a Kconfig guru could double-check... Yeah, please Kconfig gurus on the list have a quick look. Brice's patch looks fine. cu Adrian Thanks, the patch fixes the build failure with CONFIG_MYRI10GE=y, once patch for CONFIG_IXGBE are send out by Jeff Kirsher/Jesse, I will retest them. -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ehea: Fix memory hotplug support
This patch implements the memory notifier to update the busmap instantly
instead of rebuilding the whole map. This is necessary because
walk_memory_resource provides different information than required during memory
hotplug.
Signed-off-by: Hannes Hering [EMAIL PROTECTED]
---
This patch is based on the current netdev-2.6-git. It supersedes the previous
post ehea: Fix memory hotplug support.
http://www.spinics.net/lists/netdev/msg75413.html
diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea.h
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.27/drivers/net/ehea/ehea.h2008-10-14 18:26:54.0
+0200
+++ patched_kernel/drivers/net/ehea/ehea.h 2008-10-15 11:47:23.0
+0200
@@ -40,13 +40,13 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0092
+#define DRV_VERSIONEHEA_0094
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
#define DLPAR_MEM_ADD 2
#define DLPAR_MEM_REM 4
-#define EHEA_CAPABILITIES (DLPAR_PORT_ADD_REM | DLPAR_MEM_ADD)
+#define EHEA_CAPABILITIES (DLPAR_PORT_ADD_REM | DLPAR_MEM_ADD | DLPAR_MEM_REM)
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea_main.c
patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.27/drivers/net/ehea/ehea_main.c 2008-10-14 18:26:54.0
+0200
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2008-10-15 11:47:23.0
+0200
@@ -2863,7 +2863,7 @@ static void ehea_rereg_mrs(struct work_s
struct ehea_adapter *adapter;
mutex_lock(dlpar_mem_lock);
- ehea_info(LPAR memory enlarged - re-initializing driver);
+ ehea_info(LPAR memory changed - re-initializing driver);
list_for_each_entry(adapter, adapter_list, list)
if (adapter-active_ports) {
@@ -2900,13 +2900,6 @@ static void ehea_rereg_mrs(struct work_s
}
}
- ehea_destroy_busmap();
- ret = ehea_create_busmap();
- if (ret) {
- ehea_error(creating ehea busmap failed);
- goto out;
- }
-
clear_bit(__EHEA_STOP_XFER, ehea_driver_flags);
list_for_each_entry(adapter, adapter_list, list)
@@ -3519,9 +3512,21 @@ void ehea_crash_handler(void)
static int ehea_mem_notifier(struct notifier_block *nb,
unsigned long action, void *data)
{
+ struct memory_notify *arg = data;
switch (action) {
- case MEM_OFFLINE:
- ehea_info(memory has been removed);
+ case MEM_CANCEL_OFFLINE:
+ ehea_info(memory offlining canceled);
+ /* Readd canceled memory block */
+ case MEM_ONLINE:
+ ehea_info(memory is going online);
+ if (ehea_add_sect_bmap(arg-start_pfn, arg-nr_pages))
+ return NOTIFY_BAD;
+ ehea_rereg_mrs(NULL);
+ break;
+ case MEM_GOING_OFFLINE:
+ ehea_info(memory is going offline);
+ if (ehea_rem_sect_bmap(arg-start_pfn, arg-nr_pages))
+ return NOTIFY_BAD;
ehea_rereg_mrs(NULL);
break;
default:
diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea_qmr.c
patched_kernel/drivers/net/ehea/ehea_qmr.c
--- linux-2.6.27/drivers/net/ehea/ehea_qmr.c2008-10-14 18:26:54.0
+0200
+++ patched_kernel/drivers/net/ehea/ehea_qmr.c 2008-10-15 11:47:23.0
+0200
@@ -567,7 +567,7 @@ static inline int ehea_calc_index(unsign
static inline int ehea_init_top_bmap(struct ehea_top_bmap *ehea_top_bmap,
int dir)
{
- if(!ehea_top_bmap-dir[dir]) {
+ if (!ehea_top_bmap-dir[dir]) {
ehea_top_bmap-dir[dir] =
kzalloc(sizeof(struct ehea_dir_bmap), GFP_KERNEL);
if (!ehea_top_bmap-dir[dir])
@@ -578,7 +578,7 @@ static inline int ehea_init_top_bmap(str
static inline int ehea_init_bmap(struct ehea_bmap *ehea_bmap, int top, int dir)
{
- if(!ehea_bmap-top[top]) {
+ if (!ehea_bmap-top[top]) {
ehea_bmap-top[top] =
kzalloc(sizeof(struct ehea_top_bmap), GFP_KERNEL);
if (!ehea_bmap-top[top])
@@ -587,52 +587,124 @@ static inline int ehea_init_bmap(struct
return ehea_init_top_bmap(ehea_bmap-top[top], dir);
}
-static int ehea_create_busmap_callback(unsigned long pfn,
- unsigned long nr_pages, void *arg)
-{
- unsigned long i, mr_len, start_section, end_section;
- start_section = (pfn * PAGE_SIZE) / EHEA_SECTSIZE;
- end_section = start_section + ((nr_pages * PAGE_SIZE) / EHEA_SECTSIZE);
- mr_len = *(unsigned long *)arg;
+static DEFINE_MUTEX(ehea_busmap_mutex);
+static unsigned long ehea_mr_len;
- ehea_bmap = kzalloc(sizeof(struct ehea_bmap), GFP_KERNEL);
-
Re: [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64
Well, at the time of the sample, the other CPU indeed -seems- to be in
an IRQ disabled section yes.
This is not really a sample. The hardirqs enable/disable is actually tracked
using the TRACE_{EN,DIS}ABLE_INTS macros.
That's what I meant. IE. the hardirq state was updated by the stuck CPU
but sampled by the non-stuck one. ie. the non-stuck one could have
sampled a transcient value where it happened to have hard irq
disabled...
For the decrementer, the interrupt code is generated by the
STD_EXCEPTION_COMMON_LITE() macro.
Yeah, I know that :-)
Aha, none of the PPC interrupt handlers actually us TRACE_ENABLE_INTS (they do
use TRACE_DISABLE_INTS). So that's why it thinks decrementer_common disabled
interrupts, without enabling them again...
Well, they aren't supposed to enable IRQs if they were disabled...
Ben.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: SPI: specify chip select active high
The patch allows to specify that an SPI device needs an active high chip
select.
Signed-off-by: Wolfgang Ocker [EMAIL PROTECTED]
---
--- linux-2.6.27-rc7/drivers/of/of_spi.c.of_spi_cshigh 2008-09-22
00:29:55.0 +0200
+++ linux-2.6.27-rc7/drivers/of/of_spi.c2008-09-29 13:43:06.0
+0200
@@ -61,6 +61,8 @@
spi-mode |= SPI_CPHA;
if (of_find_property(nc, spi-cpol, NULL))
spi-mode |= SPI_CPOL;
+ if (of_find_property(nc, spi-cs-high, NULL))
+ spi-mode |= SPI_CS_HIGH;
/* Device speed */
prop = of_get_property(nc, spi-max-frequency, len);
--- linux-2.6.27-rc7/Documentation/powerpc/booting-without-of.txt.of_spi_cshigh
2008-09-29 14:14:08.0 +0200
+++ linux-2.6.27-rc7/Documentation/powerpc/booting-without-of.txt
2008-09-29 14:24:26.0 +0200
@@ -1917,6 +1917,8 @@
inverse clock polarity (CPOL) mode
- spi-cpha- (optional) Empty property indicating device requires
shifted clock phase (CPHA) mode
+- spi-cs-high - (optional) Empty property indicating device requires
+ chip select active high
SPI example for an MPC5200 SPI bus:
[EMAIL PROTECTED] {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add new framebuffer driver for Fujitsu MB862xx GDCs
Matteo Fortini wrote: What about the mb86290 framebuffer driver directly from Fujitsu which is in the mainline kernel? This mb86290 framebuffer driver from Fujitsu isn't in mainline, it is in the DENX Linux Kernel tree. It's from 2003 and supports only until 86293, but can it be used as a basis for a proper fb driver? It has a lot of features indeed... I think it won't be accepted in mainline. It was developed for 2.4 Kernel and slightly modified for 2.6. These features could be added to the new driver which is intended to provide initial support for Fujitsu GDCs in mainline now. Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: SPI: specify chip select active high
On Wed, Oct 15, 2008 at 03:00:47PM +0200, Wolfgang Ocker wrote:
The patch allows to specify that an SPI device needs an active high chip
select.
This look reasonable to me. Anyone else have comments on this binding?
g.
Signed-off-by: Wolfgang Ocker [EMAIL PROTECTED]
---
--- linux-2.6.27-rc7/drivers/of/of_spi.c.of_spi_cshigh2008-09-22
00:29:55.0 +0200
+++ linux-2.6.27-rc7/drivers/of/of_spi.c 2008-09-29 13:43:06.0
+0200
@@ -61,6 +61,8 @@
spi-mode |= SPI_CPHA;
if (of_find_property(nc, spi-cpol, NULL))
spi-mode |= SPI_CPOL;
+ if (of_find_property(nc, spi-cs-high, NULL))
+ spi-mode |= SPI_CS_HIGH;
/* Device speed */
prop = of_get_property(nc, spi-max-frequency, len);
---
linux-2.6.27-rc7/Documentation/powerpc/booting-without-of.txt.of_spi_cshigh
2008-09-29 14:14:08.0 +0200
+++ linux-2.6.27-rc7/Documentation/powerpc/booting-without-of.txt
2008-09-29 14:24:26.0 +0200
@@ -1917,6 +1917,8 @@
inverse clock polarity (CPOL) mode
- spi-cpha- (optional) Empty property indicating device requires
shifted clock phase (CPHA) mode
+- spi-cs-high - (optional) Empty property indicating device requires
+ chip select active high
SPI example for an MPC5200 SPI bus:
[EMAIL PROTECTED] {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add new framebuffer driver for Fujitsu MB862xx GDCs
Ok I understand. FWIW, based on my trials: * DirectFB support on BE hosts is somehow easier than with carminefb: the patches from Nikita Egorov are working almost out of the box (they basically change every single access to memory so that it becomes ABGR, so that a simple memcpy to/from Carmine memory is already the right alignment. I don't know if it would be working without these patches on kernel 2.6.26 (with FOREIGN_ENDIAN defines) since I'm currently stuck to a vanilla 2.6.24.6 * However, DirectFB has some troubles with panning, which is working using a different approach by myself: I'll check it and see if it's worth posting here. * 800x600 resolution is supported if I try [EMAIL PROTECTED] before trying [EMAIL PROTECTED] Thank you, M Anatolij Gustschin ha scritto: Matteo Fortini wrote: What about the mb86290 framebuffer driver directly from Fujitsu which is in the mainline kernel? This mb86290 framebuffer driver from Fujitsu isn't in mainline, it is in the DENX Linux Kernel tree. It's from 2003 and supports only until 86293, but can it be used as a basis for a proper fb driver? It has a lot of features indeed... I think it won't be accepted in mainline. It was developed for 2.4 Kernel and slightly modified for 2.6. These features could be added to the new driver which is intended to provide initial support for Fujitsu GDCs in mainline now. Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull 'next' branch of git://git.secretlab.ca/git/linux-2.6-mpc52xx
On Tue, Oct 14, 2008 at 03:33:46PM +0200, Wolfram Sang wrote: What about these? :) http://oldpatchwork.ozlabs.org/linuxppc-embedded/patch?id=20188 (remove obsolete code from mpc52xx_phy) I'm not going to pick this one up yet (as mentioned in my earlier email) http://oldpatchwork.ozlabs.org/linuxppc-embedded/patch?id=20189 (simplify read/write in mpc52xx_phy) http://oldpatchwork.ozlabs.org/linuxppc-embedded/patch?id=20202 (don't touch pipelining) Both of these are in my tree and I'll be asking Ben to pull soon. And to which tree did this one go? I couldn't find it on git.secretlab.ca. In the 'next' branch of my mpc52xx tree. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64
On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
On Wed, 2008-10-15 at 13:46 +0200, Geert Uytterhoeven wrote:
On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
Well, at the time of the sample, the other CPU indeed -seems- to be in
an IRQ disabled section yes.
This is not really a sample. The hardirqs enable/disable is actually
tracked
using the TRACE_{EN,DIS}ABLE_INTS macros.
That's what I meant. IE. the hardirq state was updated by the stuck CPU
but sampled by the non-stuck one. ie. the non-stuck one could have
sampled a transcient value where it happened to have hard irq
disabled...
These states are per_cpu.
I know, but that doesn't prevent another CPU from peeking at them :-)
The question is, was the message printed by the CPU that locked up or by
the other one that detected the lockup ?
It's printed by the spinlock debug code, i.e. by the CPU that wants to take the
spinlock (in this case the spinlock for the BKL).
They do call TRACE_DISABLE_INTS, which records the interrupt being disabled.
So this makes the actual state recording useless...
Well, they record that when they disable it. They don't enable it. Can
you find a spot where the IRQ is enabled and it's not recorded or a case
where it's not disabled and recorded as disabled ?
I guess it's auto-enabled when the decrementer interrupt handler exits?
So shouldn't there be a `bl trace_hardirqs_on' somewhere?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64
On Wed, 2008-10-15 at 11:25 +0200, Geert Uytterhoeven wrote: On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote: On Tue, 2008-10-14 at 11:32 +0200, Geert Uytterhoeven wrote: which points again to smp_call_function_single... Yup, it doesn't bring more information. At this stage, your 'other' CPU is stuck with interrupts disabled. Hard to tell what's happening without some HW assist. Do you have ways to trigger a non-maskable interrupt such as a 0x100 ? That would allow to catch the other guy in xmon and see what it was doing... Interrupts are not disabled on the other CPU thread, at least not according to the irqs_disabled() check I added to the printing of the `spinlock lockup' message in __spin_lock_debug(). As the log also said | hardirqs last enabled at (5018779): [c0007c1c] restore+0x1c/0xe4 | hardirqs last disabled at (5018780): [c0003600] decrementer_common+0x100/0x180 I started blinking the LEDs on decrementer interupts, which do arrive on both CPU threads. Hrm, ok I though the log shows the decrementer interrupt of the thread that's still working. If you are confident they are both taking interrupts, then there's indeed something to track down. However, I'm a bit puzzled by these `hardirqs last enabled/disabled' messages, as they do indicate interrupts are off... Well, at the time of the sample, the other CPU indeed -seems- to be in an IRQ disabled section yes. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
* Kumar Gala | 2008-10-15 08:25:54 [-0500]: On Oct 15, 2008, at 3:59 AM, Sebastian Andrzej Siewior wrote: * Sebastian Andrzej Siewior | 2008-10-15 00:49:46 [+0200]: is the -mabi=no-spe really needed? It seems to work the other way around (without -mabi=no-spe but with -mabi=no-spe) alteast I did not find anything in do_syslog() or while browsing through the dissasm. I do a boot check tomorrow. Okay. I recompiled with -mspe=no and was able to boot without trouble. It didn't work with -mabi=no-spe. I'm confused.. what did you change from your patch? This is the patch it right now: --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -103,6 +103,7 @@ KBUILD_CFLAGS += $(call cc-option,-mno-altivec) # No SPE instruction when building kernel KBUILD_CFLAGS += $(call cc-option,-mno-spe) +KBUILD_CFLAGS += $(call cc-option,-mspe=no) # Enable unit-at-a-time mode when possible. It shrinks the # kernel considerably. -- With this patch it compiles and boots fine. The option -mabi=no-spe is not required. - k Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: gigE 2.6.27 USB
Benjamin Herrenschmidt wrote: On Tue, 2008-10-14 at 03:52 -0700, Kevin Diggs wrote: Kevin Diggs wrote: Hi, I managed to wrestle my gigE to the ground and get it to boot 2.6.27. I have, however, noticed that some messages are showing up in dmesg. There are alot of them. They are continuous. They appear to come from drivers/usb/core/hub.c:2916. It looks like they come in pairs (this beast has two ports (root hubs)). I plugged in a USB CF reader. It appears to work. The keyboard and mouse (a Logitech wireless receiver) seems to work. 2.6.24 did not do this. kevin For what it is worth, I tricked a laptop into booting 2.6.27. It does not appear to generate these messages. The PowerMac is running Yellow Dog 4. It would be a lot more useful if you included informations in your report such as : - The actual error output - The full dmesg log - Informations about the adapter including output of lsusb -v - How do you actually trigger the problem It would be even more useful if you CC'ed some relevant list such as the linux-usb one too :-) Cheers, Ben. I cut a deal with my 8600 to get it to boot 2.6.27. It does not seem to work right either. The error message that shows up in dmesg is (the messages that show up for the gigE appear to be for two different busses (hubs?): hub 1-0:1.0: state 7 ports 2 chg evt hub 1-0:1.0: state 7 ports 2 chg evt hub 1-0:1.0: state 7 ports 2 chg evt hub 1-0:1.0: state 7 ports 2 chg evt lsusb does not work on this system: Unknown line at line 4969 . . . Unknown line at line 5004 lspci shows: 01:0d.0 USB Controller: Lucent Microelectronics USS-312 USB Controller (rev 10) The relevant lines from the dmesg (before they get overwritten are): ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd: block sizes: ed 64 td 64 ohci_hcd :01:0d.0: enabling device (0004 - 0006) ohci_hcd :01:0d.0: OHCI Host Controller drivers/usb/core/inode.c: creating file 'devices' drivers/usb/core/inode.c: creating file '001' ohci_hcd :01:0d.0: new USB bus registered, assigned bus number 1 ohci_hcd :01:0d.0: created debug files ohci_hcd :01:0d.0: irq 25, io mem 0x8080 ohci_hcd :01:0d.0: OHCI controller state ohci_hcd :01:0d.0: OHCI 1.0, NO legacy support registers ohci_hcd :01:0d.0: control 0x083 HCFS=operational CBSR=3 ohci_hcd :01:0d.0: cmdstatus 0x0 SOC=0 ohci_hcd :01:0d.0: intrstatus 0x0004 SF ohci_hcd :01:0d.0: intrenable 0x801a MIE UE RD WDH ohci_hcd :01:0d.0: hcca frame #001f ohci_hcd :01:0d.0: roothub.a 1202 POTPGT=16 NPS NDP=2(2) ohci_hcd :01:0d.0: roothub.b PPCM= DR= ohci_hcd :01:0d.0: roothub.status 8000 DRWE ohci_hcd :01:0d.0: roothub.portstatus [0] 0x0100 PPS ohci_hcd :01:0d.0: roothub.portstatus [1] 0x0100 PPS usb usb1: default language 0x0409 usb usb1: uevent usb usb1: usb_probe_device usb usb1: configuration #1 chosen from 1 choice usb usb1: adding 1-0:1.0 (config #1, interface 0) usb 1-0:1.0: uevent hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected hub 1-0:1.0: standalone hub hub 1-0:1.0: no power switching (usb 1.0) hub 1-0:1.0: global over-current protection hub 1-0:1.0: power on to power good time: 32ms hub 1-0:1.0: local power source is good hub 1-0:1.0: no over-current condition exists hub 1-0:1.0: trying to enable port power on non-switchable hub drivers/usb/core/inode.c: creating file '001' usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: OHCI Host Controller usb usb1: Manufacturer: Linux 2.6.27-pll-hrt ohci_hcd usb usb1: SerialNumber: :01:0d.0 hub 1-0:1.0: state 7 ports 2 chg evt usbcore: registered new interface driver libusual This is a PowerMac8600 with an OrangeLink USB Firewire card. The GigE starts spewing them immediately with no triggering event (though one should keep in mind that it uses a USB keyboard). The 8600 was fine until a gigaware USB 2 hub was plugged in (i.e. first thing plugged in). A CF reader seems to be working. The 8600 was running 2.6.26 before the upgrade to 2.6.27. I don't think it did this under 2.6.26. lsusb did work on the gigE. Thanks for the reply, Ben. kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: gigE 2.6.27 USB
On Wed, 15 Oct 2008, Kevin Diggs wrote: I cut a deal with my 8600 to get it to boot 2.6.27. It does not seem to work right either. The error message that shows up in dmesg is (the messages that show up for the gigE appear to be for two different busses (hubs?): hub 1-0:1.0: state 7 ports 2 chg evt hub 1-0:1.0: state 7 ports 2 chg evt hub 1-0:1.0: state 7 ports 2 chg evt hub 1-0:1.0: state 7 ports 2 chg evt A bug was introduced in 2.6.27 and the fix is queued for 2.6.27.stable. The fix takes the form of two patches, which you can find here: http://mirrors.med.harvard.edu/linux/kernel/people/gregkh/gregkh-2.6/gregkh-04-usb/ohci-allow-broken-controllers-to-auto-stop.patch http://mirrors.med.harvard.edu/linux/kernel/people/gregkh/gregkh-2.6/gregkh-04-usb/usb-ohci-fix-endless-polling-behavior.patch The second depends on the first, so you have to apply them both. Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: SPI: specify chip select active high
On Wed, Oct 15, 2008 at 08:22:28AM -0600, Grant Likely wrote:
On Wed, Oct 15, 2008 at 03:00:47PM +0200, Wolfgang Ocker wrote:
The patch allows to specify that an SPI device needs an active high chip
select.
This look reasonable to me. Anyone else have comments on this binding?
Looks good. I'm assuming that a spi controller has its own chip select
machine, since for GPIO chip-select we can pass active-high/low stuff
via gpios = property. But well, we can support both ways even for
GPIO chip-selects, I see no problem.
g.
Signed-off-by: Wolfgang Ocker [EMAIL PROTECTED]
---
--- linux-2.6.27-rc7/drivers/of/of_spi.c.of_spi_cshigh 2008-09-22
00:29:55.0 +0200
+++ linux-2.6.27-rc7/drivers/of/of_spi.c2008-09-29 13:43:06.0
+0200
@@ -61,6 +61,8 @@
spi-mode |= SPI_CPHA;
if (of_find_property(nc, spi-cpol, NULL))
spi-mode |= SPI_CPOL;
+ if (of_find_property(nc, spi-cs-high, NULL))
+ spi-mode |= SPI_CS_HIGH;
/* Device speed */
prop = of_get_property(nc, spi-max-frequency, len);
---
linux-2.6.27-rc7/Documentation/powerpc/booting-without-of.txt.of_spi_cshigh
2008-09-29 14:14:08.0 +0200
+++ linux-2.6.27-rc7/Documentation/powerpc/booting-without-of.txt
2008-09-29 14:24:26.0 +0200
@@ -1917,6 +1917,8 @@
inverse clock polarity (CPOL) mode
- spi-cpha- (optional) Empty property indicating device
requires
shifted clock phase (CPHA) mode
+- spi-cs-high - (optional) Empty property indicating device
requires
+ chip select active high
SPI example for an MPC5200 SPI bus:
[EMAIL PROTECTED] {
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Problems with PCI-E devices not being detected with switch
I am using the stock canyonlands 460EX development board. I have the 4L (port 1) configured as a root-complex. I also have a SIL pci-e sata card. When I plug the sata card directly into the canyonlands, everything works as expected. The sil is detected in Linux and I can read/write the disk. The sil is a 3531. The next step is to place this on the other side of a PCI-E switch. The particular switch is a PLX 8509. I connect this to the 4L port and then connect the sil to a 1L port on the 8509. When u-boot comes up, it detects all of the switch ports and the 3531 correctly. The problem occurs when Linux boots. It sees the switch (and looking in /sys/bus/... confirms it), but nothing on the downstream sides of the switch (secondary busses) is visible. There were no boot messages to indicate it had seen the Sil 3531 and it doesn't function. We've also tried other PCI-E devices (NI GPIB) on the downstream side and they are also not detected, so it seems to be something in Linux, my configuration, etc. I've included the boot messages below from u-boot and the kernel. It is more than just the pci boot messages, but I was not sure if something else in the log with provide some insight. Thanks Ayman -- AND: 128 MiB PCI: Bus Dev VenId DevId Class Int PCIE0: link is not up. PCIE0: initialization as root-complex failed PCIE1: successfully set as root-complex 03 01 10b5 8509 0604 00 03 02 10b5 8509 0604 00 06 00 1095 3531 0180 00 03 03 10b5 8509 0604 00 03 04 10b5 8509 0604 00 02 00 10b5 8509 0604 00 Net: ppc_4xx_eth0, ppc_4xx_eth1 Type run flash_nfs to mount root filesystem over NFS Hit any key to stop autoboot: 0 Waiting for PHY auto negotiation to complete.. done ENET Speed is 100 Mbps - FULL duplex connection (EMAC0) BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 *** Unhandled DHCP Option in OFFER/ACK: 7 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 7 *** Unhandled DHCP Option in OFFER/ACK: 44 DHCP client bound to address 169.254.0.102 ## Booting kernel from Legacy Image at fc00 ... Image Name: Linux-2.6.27-rc6-01149-g59c72dc- Created: 2008-09-18 22:17:29 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1616554 Bytes = 1.5 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Flattened Device Tree blob at fc1e Booting using the fdt blob at 0xfc1e ## Loading init Ramdisk from Legacy Image at fc20 ... Image Name: Tanisys Ramdisk Image Created: 2008-09-18 20:29:45 UTC Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:3320775 Bytes = 3.2 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Device Tree to 007fc000, end 007ff0c0 ... OK Loading Ramdisk to 06cd5000, end 06fffbc7 ... OK Using Canyonlands machine description Linux version 2.6.27-rc6-01149-g59c72dc-dirty ([EMAIL PROTECTED]) (gcc version 4.2.2) #9 Thu Sep 18 17:17:19 CDT 2008 Found initrd at 0xc6cd5000:0xc6fffbc7 Zone PFN ranges: DMA 0x - 0x7000 Normal 0x7000 - 0x7000 HighMem 0x7000 - 0x7000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x - 0x7000 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 28448 Kernel command line: ramdisk_size=65536 root=/dev/ram rw mem=112M ip=169.254.0.1 02:169.254.0.100:169.254.0.100:255.255.255.0:tanosx:eth0:off panic=1 console=tty S0,115200 UIC0 (32 IRQ sources) at DCR 0xc0 UIC1 (32 IRQ sources) at DCR 0xd0 UIC2 (32 IRQ sources) at DCR 0xe0 UIC3 (32 IRQ sources) at DCR 0xf0 PID hash table entries: 512 (order: 9, 2048 bytes) clocksource: timebase mult[50] shift[22] registered Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 106764k/114688k available (3188k kernel code, 7784k reserved, 124k data, 138k bss, 160k init) SLUB: Genslabs=10, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 1597.44 BogoMIPS (lpj=3194880) Mount-cache hash table entries: 512 net_namespace: 288 bytes NET: Registered protocol family 16 256k L2-cache enabled PCIE0: Checking link... PCIE0: No device detected. PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges: MEM 0x000e..0x000e7fff - 0x8000 IO 0x000f8000..0x000f8000 - 0x 4xx PCI DMA offset set to 0x PCIE0: successfully set as endpoint PCIE1: Checking link... PCIE1: Device detected, waiting for link... PCIE1: link is up ! PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges: MEM 0x000e8000..0x000e - 0x8000 IO 0x000f8001..0x000f8001 - 0x 4xx PCI DMA offset set to
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
On Oct 15, 2008, at 9:43 AM, Sebastian Andrzej Siewior wrote: * Kumar Gala | 2008-10-15 08:25:54 [-0500]: On Oct 15, 2008, at 3:59 AM, Sebastian Andrzej Siewior wrote: * Sebastian Andrzej Siewior | 2008-10-15 00:49:46 [+0200]: is the -mabi=no-spe really needed? It seems to work the other way around (without -mabi=no-spe but with -mabi=no-spe) alteast I did not find anything in do_syslog() or while browsing through the dissasm. I do a boot check tomorrow. Okay. I recompiled with -mspe=no and was able to boot without trouble. It didn't work with -mabi=no-spe. I'm confused.. what did you change from your patch? This is the patch it right now: --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -103,6 +103,7 @@ KBUILD_CFLAGS += $(call cc-option,-mno-altivec) # No SPE instruction when building kernel KBUILD_CFLAGS += $(call cc-option,-mno-spe) +KBUILD_CFLAGS += $(call cc-option,-mspe=no) # Enable unit-at-a-time mode when possible. It shrinks the # kernel considerably. -- With this patch it compiles and boots fine. The option -mabi=no-spe is not required. ok. can post a clean patch w/just this change. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull from powerpc.git next branch
On Wed, 2008-10-15 at 10:41 +0200, Arnd Bergmann wrote: On Wednesday 15 October 2008, Robert Richter wrote: there are still these OProfile patches for powerpc pending: Carl Love (1): powerpc/cell/oprofile: fix mutex locking for spu-oprofile Roel Kluin (1): powerpc/cell/oprofile: vma_map: fix test on overlay_tbl_offset Can you or Paul send them upstream? You can pull from here: git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git powerpc-for-paul The patch from Roel is already in there, with a slightly different subject line. The one from Carl is still missing. I'll put it in my tree tomorrow, it will be in the second batch. For lurkers, make sure that if you have a patch missing, it's resent and shows up in patchwork. Some patches that missed the new patchwork transition might have fallen off if paulus didn't pick them up before I took over. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64
On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote: On Tue, 2008-10-14 at 11:32 +0200, Geert Uytterhoeven wrote: which points again to smp_call_function_single... Yup, it doesn't bring more information. At this stage, your 'other' CPU is stuck with interrupts disabled. Hard to tell what's happening without some HW assist. Do you have ways to trigger a non-maskable interrupt such as a 0x100 ? That would allow to catch the other guy in xmon and see what it was doing... Interrupts are not disabled on the other CPU thread, at least not according to the irqs_disabled() check I added to the printing of the `spinlock lockup' message in __spin_lock_debug(). As the log also said | hardirqs last enabled at (5018779): [c0007c1c] restore+0x1c/0xe4 | hardirqs last disabled at (5018780): [c0003600] decrementer_common+0x100/0x180 I started blinking the LEDs on decrementer interupts, which do arrive on both CPU threads. However, I'm a bit puzzled by these `hardirqs last enabled/disabled' messages, as they do indicate interrupts are off... It could be something in the ps3vram driver causing the kernel to lockup Now the question is whether the kernel is stuffed with something like a deadlock with interrupts off, or is it a HW problem causing a CPU to lockup on an access to the vram ? It's not related to the ps3vram driver, as it happens without, too. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
* Sebastian Andrzej Siewior | 2008-10-15 00:49:46 [+0200]: is the -mabi=no-spe really needed? It seems to work the other way around (without -mabi=no-spe but with -mabi=no-spe) alteast I did not find anything in do_syslog() or while browsing through the dissasm. I do a boot check tomorrow. Okay. I recompiled with -mspe=no and was able to boot without trouble. It didn't work with -mabi=no-spe. - k Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
On Oct 15, 2008, at 3:59 AM, Sebastian Andrzej Siewior wrote: * Sebastian Andrzej Siewior | 2008-10-15 00:49:46 [+0200]: is the -mabi=no-spe really needed? It seems to work the other way around (without -mabi=no-spe but with -mabi=no-spe) alteast I did not find anything in do_syslog() or while browsing through the dissasm. I do a boot check tomorrow. Okay. I recompiled with -mspe=no and was able to boot without trouble. It didn't work with -mabi=no-spe. I'm confused.. what did you change from your patch? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64
On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
Well, at the time of the sample, the other CPU indeed -seems- to be in
an IRQ disabled section yes.
This is not really a sample. The hardirqs enable/disable is actually tracked
using the TRACE_{EN,DIS}ABLE_INTS macros.
That's what I meant. IE. the hardirq state was updated by the stuck CPU
but sampled by the non-stuck one. ie. the non-stuck one could have
sampled a transcient value where it happened to have hard irq
disabled...
These states are per_cpu.
Aha, none of the PPC interrupt handlers actually us TRACE_ENABLE_INTS (they
do
use TRACE_DISABLE_INTS). So that's why it thinks decrementer_common disabled
interrupts, without enabling them again...
Well, they aren't supposed to enable IRQs if they were disabled...
They do call TRACE_DISABLE_INTS, which records the interrupt being disabled.
So this makes the actual state recording useless...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] kexec memory ranges dynamic allocation
Patch corrected. ( git_kexec_powerpc_v2.patch is attached.)
I tested it on ppc64 pasemi electra board. Both kexec -l and kexec -p works.
Maxim.
2008/10/15 Simon Horman [EMAIL PROTECTED]
On Tue, Oct 14, 2008 at 07:11:19PM +0400, Maxim Uvarov wrote:
Hello all,
As you all know it is not easy to count exact value of memory ranges from
device tree on powerpc.
It very depends on how dts file was written. What do you think about
really
dynamic allocation buffers
for this buffers?
Conceptually I have no objections to the change,
though I would like to get some review from ppc people.
(linuxppc-dev@ozlabs.org CCed)
Patch is attached.
This patch doesn't seem to compile for me.
# powerpc64-unknown-linux-gnu-gcc --version
powerpc64-unknown-linux-gnu-gcc (GCC) 4.1.1
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#make
[snip]
kexec/arch/ppc64/kexec-ppc64.c:100: warning: function declaration isn't a
prototype
kexec/arch/ppc64/kexec-ppc64.c: In function 'realloc_memory_ranges':
kexec/arch/ppc64/kexec-ppc64.c:107: warning: passing argument 1 of
'realloc' makes pointer from integer without a cast
kexec/arch/ppc64/kexec-ppc64.c:107: error: too few arguments to function
'realloc'
kexec/arch/ppc64/kexec-ppc64.c:102: warning: unused variable 'tmp'
--
Simon Horman
VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
H: www.vergenet.net/~horms/ http://www.vergenet.net/%7Ehorms/
W: www.valinux.co.jp/en
--
Best regards,
Maxim Uvarov
diff --git a/kexec/arch/ppc64/kexec-ppc64.c b/kexec/arch/ppc64/kexec-ppc64.c
index 069a9fc..0ad40fa 100644
--- a/kexec/arch/ppc64/kexec-ppc64.c
+++ b/kexec/arch/ppc64/kexec-ppc64.c
@@ -96,96 +96,46 @@ err1:
}
-static int count_dyn_reconf_memory_ranges(void)
+static int realloc_memory_ranges()
{
- char device_tree[] = /proc/device-tree/;
- char fname[128];
- char buf[32];
- FILE *file;
-
- strcpy(fname, device_tree);
- strcat(fname, ibm,dynamic-reconfiguration-memory/ibm,lmb-size);
- if ((file = fopen(fname, r)) == NULL) {
- perror(fname);
- return -1;
- }
+ size_t memory_range_len;
- if (fread(buf, 1, 8, file) 0) {
- perror(fname);
- fclose(file);
- return -1;
- }
-
- lmb_size = ((uint64_t *)buf)[0];
- fclose(file);
+ max_memory_ranges++;
+ memory_range_len = sizeof(struct memory_range) * max_memory_ranges;
- /* Get number of lmbs from ibm,dynamic-memory */
- strcpy(fname, device_tree);
- strcat(fname, ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory);
- if ((file = fopen(fname, r)) == NULL) {
- perror(fname);
- return -1;
- }
- /*
- * first 4 bytes provide number of entries(lmbs)
- */
- if (fread(buf, 1, 4, file) 0) {
- perror(fname);
- fclose(file);
- return -1;
- }
- num_of_lmbs = ((unsigned int *)buf)[0];
- max_memory_ranges += num_of_lmbs;
- fclose(file);
+ memory_range = (struct memory_range *) realloc(memory_range, memory_range_len);
+ if (!memory_range)
+ goto err;
- return 0;
-}
+ base_memory_range = (struct memory_range *) realloc(memory_range, memory_range_len);
+ if (!base_memory_range)
+ goto err;
-/*
- * Count the memory nodes under /proc/device-tree and populate the
- * max_memory_ranges variable. This variable replaces MAX_MEMORY_RANGES
- * macro used earlier.
- */
-static int count_memory_ranges(void)
-{
- char device_tree[256] = /proc/device-tree/;
- struct dirent *dentry;
- DIR *dir;
+ exclude_range = (struct memory_range *) realloc(exclude_range, memory_range_len);
+ if (!exclude_range)
+ goto err;
- if ((dir = opendir(device_tree)) == NULL) {
- perror(device_tree);
- return -1;
- }
+ usablemem_rgns.ranges = (struct memory_range *)
+realloc(usablemem_rgns.ranges, memory_range_len);
+ if (!(usablemem_rgns.ranges))
+ goto err;
- while ((dentry = readdir(dir)) != NULL) {
- if (!strncmp(dentry-d_name,
-ibm,dynamic-reconfiguration-memory, 35)){
- if (count_dyn_reconf_memory_ranges() != 0)
-return -1;
- continue;
- }
+ return 0;
- if (strncmp(dentry-d_name, memory@, 7)
- strcmp(dentry-d_name, memory)
- strncmp(dentry-d_name, pci@, 4))
- continue;
- max_memory_ranges++;
- }
- /* need to add extra region for retained initrd */
- if (reuse_initrd) {
- max_memory_ranges++;
- }
+err:
+ fprintf(stderr, memory range structure re-allocation failure\n);
+ return -1;
+}
- closedir(dir);
- return 0;
-}
static void add_base_memory_range(uint64_t start, uint64_t end)
{
base_memory_range[nr_memory_ranges].start = start;
base_memory_range[nr_memory_ranges].end = end;
base_memory_range[nr_memory_ranges].type = RANGE_RAM;
nr_memory_ranges++;
+ if (nr_memory_ranges = max_memory_ranges)
+ realloc_memory_ranges();
dbgprintf(%016llx-%016llx : %x\n,
base_memory_range[nr_memory_ranges-1].start,
@@ -300,8 +250,8 @@ static int get_base_ranges(void)
return -1;
}
if
Re: [PATCH] powerpc: Add legacy PCI access via sysfs (v3)
On Monday, October 13, 2008 5:55 pm Benjamin Herrenschmidt wrote: This patch adds support for legacy_io and legacy_mem files in bus class directories in sysfs for powerpc Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Ok, applied this one. Should be pushing to Linus soon. Thanks, Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64
On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
On Wed, 2008-10-15 at 11:25 +0200, Geert Uytterhoeven wrote:
On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
On Tue, 2008-10-14 at 11:32 +0200, Geert Uytterhoeven wrote:
which points again to smp_call_function_single...
Yup, it doesn't bring more information. At this stage, your 'other' CPU
is stuck with interrupts disabled. Hard to tell what's happening without
some HW assist. Do you have ways to trigger a non-maskable interrupt
such as a 0x100 ? That would allow to catch the other guy in xmon and
see what it was doing...
Interrupts are not disabled on the other CPU thread, at least not according
to
the irqs_disabled() check I added to the printing of the `spinlock lockup'
message in __spin_lock_debug().
As the log also said
| hardirqs last enabled at (5018779): [c0007c1c]
restore+0x1c/0xe4
| hardirqs last disabled at (5018780): [c0003600]
decrementer_common+0x100/0x180
I started blinking the LEDs on decrementer interupts, which do arrive on
both
CPU threads.
Hrm, ok I though the log shows the decrementer interrupt of the thread
that's still working. If you are confident they are both taking
interrupts, then there's indeed something to track down.
However, I'm a bit puzzled by these `hardirqs last enabled/disabled'
messages,
as they do indicate interrupts are off...
Well, at the time of the sample, the other CPU indeed -seems- to be in
an IRQ disabled section yes.
This is not really a sample. The hardirqs enable/disable is actually tracked
using the TRACE_{EN,DIS}ABLE_INTS macros.
For the decrementer, the interrupt code is generated by the
STD_EXCEPTION_COMMON_LITE() macro.
Aha, none of the PPC interrupt handlers actually us TRACE_ENABLE_INTS (they do
use TRACE_DISABLE_INTS). So that's why it thinks decrementer_common disabled
interrupts, without enabling them again...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Move memory size print into common show_cpuinfo for 32-bit
Most of the platforms were printing the size of the memory
in their show_cpuinfo implementations. This moves that to
the common show_cpuinfo, so that all 32-bit platforms will
now print the size of memory. I also update the code
to deal with the fact that total_memory is now a phys_addr_t.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/kernel/setup-common.c |7 +++
arch/powerpc/platforms/85xx/ksi8560.c |4
arch/powerpc/platforms/85xx/mpc85xx_ads.c |4
arch/powerpc/platforms/85xx/mpc85xx_cds.c |4
arch/powerpc/platforms/85xx/sbc8548.c |4
arch/powerpc/platforms/85xx/sbc8560.c |4
arch/powerpc/platforms/85xx/stx_gp3.c |4
arch/powerpc/platforms/85xx/tqm85xx.c |4
arch/powerpc/platforms/86xx/gef_sbc610.c |2 --
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |2 --
arch/powerpc/platforms/86xx/sbc8641d.c |2 --
arch/powerpc/platforms/embedded6xx/c2k.c |3 ---
arch/powerpc/platforms/embedded6xx/prpmc2800.c |3 ---
13 files changed, 7 insertions(+), 40 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 5ec56ff..705fc4b 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -59,6 +59,7 @@
#include asm/mmu.h
#include asm/xmon.h
#include asm/cputhreads.h
+#include mm/mmu_decl.h
#include setup.h
@@ -190,6 +191,12 @@ static int show_cpuinfo(struct seq_file *m, void *v)
if (ppc_md.show_cpuinfo != NULL)
ppc_md.show_cpuinfo(m);
+#ifdef CONFIG_PPC32
+ /* Display the amount of memory */
+ seq_printf(m, Memory\t\t: %d MB\n,
+ (unsigned int)(total_memory / (1024 * 1024)));
+#endif
+
return 0;
}
diff --git a/arch/powerpc/platforms/85xx/ksi8560.c
b/arch/powerpc/platforms/85xx/ksi8560.c
index 8a3b117..81cee7b 100644
--- a/arch/powerpc/platforms/85xx/ksi8560.c
+++ b/arch/powerpc/platforms/85xx/ksi8560.c
@@ -193,7 +193,6 @@ static void __init ksi8560_setup_arch(void)
static void ksi8560_show_cpuinfo(struct seq_file *m)
{
uint pvid, svid, phid1;
- uint memsize = total_memory;
pvid = mfspr(SPRN_PVR);
svid = mfspr(SPRN_SVR);
@@ -215,9 +214,6 @@ static void ksi8560_show_cpuinfo(struct seq_file *m)
/* Display cpu Pll setting */
phid1 = mfspr(SPRN_HID1);
seq_printf(m, PLL setting\t: 0x%x\n, ((phid1 24) 0x3f));
-
- /* Display the amount of memory */
- seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
}
static struct of_device_id __initdata of_bus_ids[] = {
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index 0293e3d..21f0090 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -207,7 +207,6 @@ static void __init mpc85xx_ads_setup_arch(void)
static void mpc85xx_ads_show_cpuinfo(struct seq_file *m)
{
uint pvid, svid, phid1;
- uint memsize = total_memory;
pvid = mfspr(SPRN_PVR);
svid = mfspr(SPRN_SVR);
@@ -219,9 +218,6 @@ static void mpc85xx_ads_show_cpuinfo(struct seq_file *m)
/* Display cpu Pll setting */
phid1 = mfspr(SPRN_HID1);
seq_printf(m, PLL setting\t: 0x%x\n, ((phid1 24) 0x3f));
-
- /* Display the amount of memory */
- seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
}
static struct of_device_id __initdata of_bus_ids[] = {
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 50d7ea8..aeb6a5b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -307,7 +307,6 @@ static void __init mpc85xx_cds_setup_arch(void)
static void mpc85xx_cds_show_cpuinfo(struct seq_file *m)
{
uint pvid, svid, phid1;
- uint memsize = total_memory;
pvid = mfspr(SPRN_PVR);
svid = mfspr(SPRN_SVR);
@@ -320,9 +319,6 @@ static void mpc85xx_cds_show_cpuinfo(struct seq_file *m)
/* Display cpu Pll setting */
phid1 = mfspr(SPRN_HID1);
seq_printf(m, PLL setting\t: 0x%x\n, ((phid1 24) 0x3f));
-
- /* Display the amount of memory */
- seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
}
diff --git a/arch/powerpc/platforms/85xx/sbc8548.c
b/arch/powerpc/platforms/85xx/sbc8548.c
index b9246ea..7ec77ce 100644
--- a/arch/powerpc/platforms/85xx/sbc8548.c
+++ b/arch/powerpc/platforms/85xx/sbc8548.c
@@ -136,7 +136,6 @@ static void __init sbc8548_setup_arch(void)
static void sbc8548_show_cpuinfo(struct seq_file *m)
{
uint pvid, svid, phid1;
- uint memsize = total_memory;
pvid = mfspr(SPRN_PVR);
svid = mfspr(SPRN_SVR);
@@ -149,9 +148,6 @@ static void
Proposal for a Generic PWM Device API posted on linux-embedded
Greetings, all! I just posted code to implement a Generic PWM Device API to linux-embedded. If you need them, archives of that mailing list are available at the following link (and elsewhere): http://www.mail-archive.com/[EMAIL PROTECTED]/ Previous versions of this code were posted on linux-arm-kernel, linuxppc-dev, avr32linux.org and elsewhere. It's an API that cuts across machine architectures--- not unlike the GPIO API--- and I really appreciate the constructive feedback I have received from all corners of the architecture globe. Multiple reviewers suggested that the best place to review the final code is linux-embedded, rather than cross-posting all over the place. I encourage you to submit your feedback there. I would love to see this code included in the mainline kernel at some point in the not-too-distant future. It has proven very useful to me, I think it will be useful for many others as well. Kindest regards, b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH, RESEND] powerpc/cell/oprofile: fix mutex locking for spu-oprofile
From aa5810fa545515c9f383e3e649bd120bef9c7f29 Mon Sep 17 00:00:00 2001
From: Carl Love [EMAIL PROTECTED]
Date: Fri, 8 Aug 2008 15:38:36 -0700
Subject: [PATCH] powerpc/cell/oprofile: fix mutex locking for spu-oprofile
The issue is the SPU code is not holding the kernel mutex lock while
adding samples to the kernel buffer.
This patch creates per SPU buffers to hold the data. Data
is added to the buffers from in interrupt context. The data
is periodically pushed to the kernel buffer via a new Oprofile
function oprofile_put_buff(). The oprofile_put_buff() function
is called via a work queue enabling the funtion to acquire the
mutex lock.
The existing user controls for adjusting the per CPU buffer
size is used to control the size of the per SPU buffers.
Similarly, overflows of the SPU buffers are reported by
incrementing the per CPU buffer stats. This eliminates the
need to have architecture specific controls for the per SPU
buffers which is not acceptable to the OProfile user tool
maintainer.
The export of the oprofile add_event_entry() is removed as it
is no longer needed given this patch.
Note, this patch has not addressed the issue of indexing arrays
by the spu number. This still needs to be fixed as the spu
numbering is not guarenteed to be 0 to max_num_spus-1.
Signed-off-by: Carl Love [EMAIL PROTECTED]
Signed-off-by: Maynard Johnson [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Acked-by: Acked-by: Robert Richter [EMAIL PROTECTED]
---
arch/powerpc/oprofile/cell/pr_util.h | 13 ++
arch/powerpc/oprofile/cell/spu_profiler.c |4 +-
arch/powerpc/oprofile/cell/spu_task_sync.c | 236 +---
drivers/oprofile/buffer_sync.c | 24 +++
drivers/oprofile/cpu_buffer.c | 15 ++-
drivers/oprofile/event_buffer.h|7 +
include/linux/oprofile.h | 16 +-
7 files changed, 279 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/oprofile/cell/pr_util.h
b/arch/powerpc/oprofile/cell/pr_util.h
index 22e4e8d..628009c 100644
--- a/arch/powerpc/oprofile/cell/pr_util.h
+++ b/arch/powerpc/oprofile/cell/pr_util.h
@@ -24,6 +24,11 @@
#define SKIP_GENERIC_SYNC 0
#define SYNC_START_ERROR -1
#define DO_GENERIC_SYNC 1
+#define SPUS_PER_NODE 8
+#define DEFAULT_TIMER_EXPIRE (HZ / 10)
+
+extern struct delayed_work spu_work;
+extern int spu_prof_running;
struct spu_overlay_info { /* map of sections within an SPU overlay */
unsigned int vma; /* SPU virtual memory address from elf */
@@ -62,6 +67,14 @@ struct vma_to_fileoffset_map { /* map of sections
within an SPU program */
};
+struct spu_buffer {
+ int last_guard_val;
+ int ctx_sw_seen;
+ unsigned long *buff;
+ unsigned int head, tail;
+};
+
+
/* The three functions below are for maintaining and accessing
* the vma-to-fileoffset map.
*/
diff --git a/arch/powerpc/oprofile/cell/spu_profiler.c
b/arch/powerpc/oprofile/cell/spu_profiler.c
index 380d7e2..6edaebd 100644
--- a/arch/powerpc/oprofile/cell/spu_profiler.c
+++ b/arch/powerpc/oprofile/cell/spu_profiler.c
@@ -23,12 +23,11 @@
static u32 *samples;
-static int spu_prof_running;
+int spu_prof_running;
static unsigned int profiling_interval;
#define NUM_SPU_BITS_TRBUF 16
#define SPUS_PER_TB_ENTRY 4
-#define SPUS_PER_NODE 8
#define SPU_PC_MASK 0x
@@ -208,6 +207,7 @@ int start_spu_profiling(unsigned int cycles_reset)
spu_prof_running = 1;
hrtimer_start(timer, kt, HRTIMER_MODE_REL);
+ schedule_delayed_work(spu_work, DEFAULT_TIMER_EXPIRE);
return 0;
}
diff --git a/arch/powerpc/oprofile/cell/spu_task_sync.c
b/arch/powerpc/oprofile/cell/spu_task_sync.c
index 2a9b4a0..2949126 100644
--- a/arch/powerpc/oprofile/cell/spu_task_sync.c
+++ b/arch/powerpc/oprofile/cell/spu_task_sync.c
@@ -35,7 +35,102 @@ static DEFINE_SPINLOCK(buffer_lock);
static DEFINE_SPINLOCK(cache_lock);
static int num_spu_nodes;
int spu_prof_num_nodes;
-int last_guard_val[MAX_NUMNODES * 8];
+
+struct spu_buffer spu_buff[MAX_NUMNODES * SPUS_PER_NODE];
+struct delayed_work spu_work;
+static unsigned max_spu_buff;
+
+static void spu_buff_add(unsigned long int value, int spu)
+{
+ /* spu buff is a circular buffer. Add entries to the
+* head. Head is the index to store the next value.
+* The buffer is full when there is one available entry
+* in the queue, i.e. head and tail can't be equal.
+* That way we can tell the difference between the
+* buffer being full versus empty.
+*
+* ASSUPTION: the buffer_lock is held when this function
+* is called to lock the buffer, head and tail.
+*/
+ int full = 1;
+
+ if (spu_buff[spu].head = spu_buff[spu].tail) {
+ if ((spu_buff[spu].head - spu_buff[spu].tail)
+ (max_spu_buff - 1))
+ full = 0;
+
+ } else if
Re: [git pull] Please pull from powerpc.git next branch
On Wednesday 15 October 2008, Robert Richter wrote: there are still these OProfile patches for powerpc pending: Carl Love (1): powerpc/cell/oprofile: fix mutex locking for spu-oprofile Roel Kluin (1): powerpc/cell/oprofile: vma_map: fix test on overlay_tbl_offset Can you or Paul send them upstream? You can pull from here: git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git powerpc-for-paul The patch from Roel is already in there, with a slightly different subject line. The one from Carl is still missing. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull from powerpc.git next branch
Ben, there are still these OProfile patches for powerpc pending: Carl Love (1): powerpc/cell/oprofile: fix mutex locking for spu-oprofile Roel Kluin (1): powerpc/cell/oprofile: vma_map: fix test on overlay_tbl_offset Can you or Paul send them upstream? You can pull from here: git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git powerpc-for-paul Thanks, -Robert On 15.10.08 12:16:36, Benjamin Herrenschmidt wrote: Hi Linus ! Here's the powerpc main batch for 2.6.28. It's a bit late mostly due to both Paul and I being distracted by other things at the wrong time, and me trying to run some more tests ( fixing regressions) before sending it all to you. There's a bunch of stuff in there, most of it in arch/powerpc, but you'll notice a few things touching files out of it. Here's a short summary of these: - These are just a trivial change of CONFIG_PPC_MERGE - CONFIG_PPC since the former is no longer useful now that arch/ppc is gone drivers/block/floppy.c drivers/char/ipmi/ipmi_si_intf.c drivers/i2c/busses/i2c-pca-isa.c drivers/input/serio/i8042-io.h drivers/pnp/isapnp/core.c drivers/pnp/pnpbios/core.c - Some other trivial #include fixes for the move of of_device.h from asm/ to linux/ drivers/hwmon/ams/ams.h sound/aoa/soundbus/soundbus.h - The math-emu changes are two fold. Some trivial compile warning fixes and some changes to improve exception reporting acked by davem. Now powerpc uses the generic math-emu code too - Some powerpc specific drivers. They should all have appropriate acks with the possible exception of the pata_of_platform.c one which I merged in while jeff was away and hvc_console for which I believe we are still maintainers of. - Some drivers/of additions that should (hopefully) be of no impact to other users of the OF stuff - a procfs change removing our obsolete ppc_htab stuff And that should be it, hopefully I didn't miss anything :-) I did a merge with your tree to fixup a couple of conflicts so it should be a smooth merge on your side. Cheers, Ben. The following changes since commit 8acd3a60bcca17c6d89c73cee3ad6057eb83ba1e: Linus Torvalds (1): Merge branch 'for-2.6.28' of git://linux-nfs.org/~bfields/linux are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next Adrian Bunk (1): powerpc: Use bcd2bin/bin2bcd Anton Vorontsov (12): powerpc/83xx: mpc836x_mds: add support for the nor flash powerpc/fsl_soc: remove mpc83xx_wdt code OF: add fsl,mcu-mpc8349emitx to the exception list powerpc: Fix no interrupt handling in pata_of_platform of: Add new helper of_parse_phandles_with_args() powerpc/QE: move QE_GPIO Kconfig symbol into the platforms/Kconfig powerpc/83xx: don't probe broken PCI on mpc837x_mds boards powerpc/83xx: add DS1374 RTC support for the MPC837xE-MDS boards OF: add fsl,mcu-mpc8349emitx to the exception list i2c: MPC8349E-mITX Power Management and GPIO expander driver powerpc/83xx: add NAND support for the MPC8360E-RDK boards powerpc: fix fsl_upm nand driver modular build Becky Bruce (10): powerpc: Rename PTE_SIZE to HPTE_SIZE powerpc/85xx: fix build warning, remove silly cast cpm_uart: Pass actual dev ptr to dma_* in ucc and cpm_uart serial powerpc: Rename dma_64.c to dma.c powerpc: Move iommu dma ops from dma.c to dma-iommu.c powerpc: Drop archdata numa_node powerpc: Merge 32 and 64-bit dma code powerpc: Make dma_addr_t a u64 if CONFIG_PHYS_64BIT is set POWERPC: Allow 32-bit hashed pgtable code to support 36-bit physical powerpc: Drop redundant machine type print in show_cpuinfo Benjamin Herrenschmidt (16): powerpc: Turn get/set_hard_smp_proccessor_id into inlines powerpc: Expose PMCs cache topology in sysfs on 32-bit Merge commit 'kumar/kumar-dma' Merge commit 'kumar/kumar-mmu' Merge commit 'jwb/jwb-next' powerpc: Fix sysfs pci mmap on 32-bit machines with 64-bit PCI Merge commit 'jk/jk-merge' Merge commit 'gcl/gcl-next' Merge commit 'kumar/kumar-next' powerpc: Fix DMA offset for non-coherent DMA powerpc/pci: Improve detection of unassigned bridge resources powerpc: Fix link errors on 32-bit machines using legacy DMA powerpc: Fix 32-bit SMP boot on CHRP powerpc/chrp: Fix detection of Python PCI host bridge on IBM CHRPs powerpc: Fix CHRP PCI config access for indirect_pci Merge commit 'origin' Chandru (1): powerpc: Add support for dynamic reconfiguration memory in kexec/kdump kernels Christian Borntraeger (1): hvc_console: Fix free_irq in spinlocked section Christoph Hellwig (1): powerpc: Use sys_pause for 32-bit pause entry point
Re: [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64
On Wed, 2008-10-15 at 13:46 +0200, Geert Uytterhoeven wrote:
On Wed, 15 Oct 2008, Benjamin Herrenschmidt wrote:
Well, at the time of the sample, the other CPU indeed -seems- to be in
an IRQ disabled section yes.
This is not really a sample. The hardirqs enable/disable is actually
tracked
using the TRACE_{EN,DIS}ABLE_INTS macros.
That's what I meant. IE. the hardirq state was updated by the stuck CPU
but sampled by the non-stuck one. ie. the non-stuck one could have
sampled a transcient value where it happened to have hard irq
disabled...
These states are per_cpu.
I know, but that doesn't prevent another CPU from peeking at them :-)
The question is, was the message printed by the CPU that locked up or by
the other one that detected the lockup ?
They do call TRACE_DISABLE_INTS, which records the interrupt being disabled.
So this makes the actual state recording useless...
Well, they record that when they disable it. They don't enable it. Can
you find a spot where the IRQ is enabled and it's not recorded or a case
where it's not disabled and recorded as disabled ?
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PROBLEM] Soft lockup on Linux 2.6.27, 2 patches, Cell/PPC64
On Wed, 2008-10-15 at 14:05 +0200, Geert Uytterhoeven wrote: I guess it's auto-enabled when the decrementer interrupt handler exits? So shouldn't there be a `bl trace_hardirqs_on' somewhere? The interrupts are restored to their previous state on exit of interrupts via the TRACE_AND_RESTORE_IRQ() macro which is called from entry_64.S in the main restore path and in head_64.S in the fast path and hashing faults. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add legacy PCI access via sysfs (v3)
On Wed, 2008-10-15 at 05:16 -0700, Jesse Barnes wrote: On Monday, October 13, 2008 5:55 pm Benjamin Herrenschmidt wrote: This patch adds support for legacy_io and legacy_mem files in bus class directories in sysfs for powerpc Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Ok, applied this one. Should be pushing to Linus soon. Thanks ! Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC PATCH] Support for big page sizes on 44x (Updated)
These patches add support for selecting page size on PPC 44x. First one adds support for 16K/64K pages while second one adds support for 256K pages along with some hacks. However there are still number of problems: 1. We can't use default PKMAP_BASE definition with 64KB/256KB pages so we change it. Not sure that it's optimal. Then redefined PKMAP_BASE is not aligned on (1PMD_SHIFT), don't know if it is really bad. 2. with 16KB/64KB/256KB pages WARN_ON(!pmd_none(*pmd)) is triggered inside dma_alloc_init() function. Not sure if it is really bad. 3. with 256KB pages ENTRIES_PER_PAGEPAGE in mm/shem.c become zero. 4. We use asm-offsets mechanism to make PTE_SHIFT/PMD_SHIFT available in assembler but we don't really need the power of asm-offsets here. Maybe it will be more convinient to just take these defines out of #ifndef __ASSEMBLY__? But this would change asm-generic... We would appreciate any comment. Regards, Ilya. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
This patch adds support for page sizes bigger than 4K (16K/64K) on
PPC 44x.
Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED]
Signed-off-by: Vladimir Panfilov [EMAIL PROTECTED]
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
---
arch/powerpc/Kconfig | 26 --
arch/powerpc/include/asm/highmem.h |8 +++-
arch/powerpc/include/asm/mmu-44x.h | 18 ++
arch/powerpc/include/asm/page.h| 13 -
arch/powerpc/include/asm/pgtable.h |3 +++
arch/powerpc/kernel/asm-offsets.c |4
arch/powerpc/kernel/head_44x.S | 22 +-
arch/powerpc/kernel/misc_32.S | 12 ++--
arch/powerpc/mm/pgtable_32.c |9 ++---
arch/powerpc/platforms/Kconfig.cputype |2 +-
10 files changed, 82 insertions(+), 35 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 587da5e..9627cfd 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -402,16 +402,30 @@ config PPC_HAS_HASH_64K
depends on PPC64
default n
-config PPC_64K_PAGES
- bool 64k page size
- depends on PPC64
- select PPC_HAS_HASH_64K
+choice
+ prompt Page size
+ default PPC_4K_PAGES
help
- This option changes the kernel logical page size to 64k. On machines
+ The PAGE_SIZE definition. Increasing the page size may
+ improve the system performance in some dedicated cases like software
+ RAID with accelerated calculations. In PPC64 case on machines
without processor support for 64k pages, the kernel will simulate
them by loading each individual 4k page on demand transparently,
while on hardware with such support, it will be used to map
normal application pages.
+ If unsure, set it to 4 KB.
+
+config PPC_4K_PAGES
+ bool 4k page size
+
+config PPC_16K_PAGES
+ bool 16k page size if 44x
+
+config PPC_64K_PAGES
+ bool 64k page size if 44x || PPC64
+ select PPC_HAS_HASH_64K if PPC64
+
+endchoice
config FORCE_MAX_ZONEORDER
int Maximum zone order
@@ -435,7 +449,7 @@ config FORCE_MAX_ZONEORDER
config PPC_SUBPAGE_PROT
bool Support setting protections for 4k subpages
- depends on PPC_64K_PAGES
+ depends on PPC64 PPC_64K_PAGES
help
This option adds support for a system call to allow user programs
to set access permissions (read/write, readonly, or no access)
diff --git a/arch/powerpc/include/asm/highmem.h
b/arch/powerpc/include/asm/highmem.h
index 5d99b64..dc1132c 100644
--- a/arch/powerpc/include/asm/highmem.h
+++ b/arch/powerpc/include/asm/highmem.h
@@ -38,9 +38,15 @@ extern pte_t *pkmap_page_table;
* easily, subsequent pte tables have to be allocated in one physical
* chunk of RAM.
*/
+#if defined(CONFIG_PPC_64K_PAGES) !defined(CONFIG_PPC64)
+#define PKMAP_ORDER(27 - PAGE_SHIFT)
+#define LAST_PKMAP (1 PKMAP_ORDER)
+#define PKMAP_BASE (FIXADDR_START - PAGE_SIZE*(LAST_PKMAP + 1))
+#else
#define LAST_PKMAP (1 PTE_SHIFT)
-#define LAST_PKMAP_MASK (LAST_PKMAP-1)
#define PKMAP_BASE ((FIXADDR_START - PAGE_SIZE*(LAST_PKMAP + 1))
PMD_MASK)
+#endif
+#define LAST_PKMAP_MASK(LAST_PKMAP-1)
#define PKMAP_NR(virt) ((virt-PKMAP_BASE) PAGE_SHIFT)
#define PKMAP_ADDR(nr) (PKMAP_BASE + ((nr) PAGE_SHIFT))
diff --git a/arch/powerpc/include/asm/mmu-44x.h
b/arch/powerpc/include/asm/mmu-44x.h
index a825524..2ca18e8 100644
--- a/arch/powerpc/include/asm/mmu-44x.h
+++ b/arch/powerpc/include/asm/mmu-44x.h
@@ -4,6 +4,8 @@
* PPC440 support
*/
+#include asm/page.h
+
#define PPC44x_MMUCR_TID 0x00ff
#define PPC44x_MMUCR_STS 0x0001
@@ -73,4 +75,20 @@ typedef struct {
/* Size of the TLBs used for pinning in lowmem */
#define PPC_PIN_SIZE (1 28) /* 256M */
+#if (PAGE_SHIFT == 12)
+#define PPC44x_TLBE_SIZE PPC44x_TLB_4K
+#elif (PAGE_SHIFT == 14)
+#define PPC44x_TLBE_SIZE PPC44x_TLB_16K
+#elif (PAGE_SHIFT == 16)
+#define PPC44x_TLBE_SIZE PPC44x_TLB_64K
+#else
+#error Unsupported PAGE_SIZE
+#endif
+
+#define PPC44x_PGD_OFF_SHIFT (32 - PMD_SHIFT + 2)
+#define PPC44x_PGD_OFF_MASK(PMD_SHIFT - 2)
+#define PPC44x_PTE_ADD_SHIFT (32 - PMD_SHIFT + PTE_SHIFT + 3)
+#define PPC44x_PTE_ADD_MASK(32 - 3 - PTE_SHIFT)
+#define PPC44x_RPN_MASK(31 - PAGE_SHIFT)
+
#endif /* _ASM_POWERPC_MMU_44X_H_ */
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index e088545..537d5b1 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -15,12 +15,15 @@
#include asm/types.h
/*
- * On PPC32 page size is 4K. For PPC64 we support either 4K or 64K software
+ * On regular PPC32 page size is 4K (but we support 4K/16K/64K pages
+ * on PPC44x). For PPC64 we support either 4K or 64K software
* page size. When using 64K pages however, whether we are
[PATCH 2/2] powerpc: support for 256K pages on PPC 44x
This patch adds support for 256K pages on PPC 44x along with
some hacks needed for this.
Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED]
Signed-off-by: Vladimir Panfilov [EMAIL PROTECTED]
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |8
arch/powerpc/include/asm/highmem.h |3 ++-
arch/powerpc/include/asm/mmu-44x.h |2 ++
arch/powerpc/include/asm/page.h|6 --
arch/powerpc/include/asm/page_32.h |4
arch/powerpc/include/asm/thread_info.h |4
arch/powerpc/kernel/head_booke.h | 11 +--
7 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9627cfd..7df5528 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -425,6 +425,14 @@ config PPC_64K_PAGES
bool 64k page size if 44x || PPC64
select PPC_HAS_HASH_64K if PPC64
+config PPC_256K_PAGES
+ bool 256k page size if 44x
+ depends on BROKEN
+ help
+ ELF standard supports only page sizes up to 64K so you need a patched
+ binutils in order to use 256K pages. Chose it only if you know what
+ you are doing.
+
endchoice
config FORCE_MAX_ZONEORDER
diff --git a/arch/powerpc/include/asm/highmem.h
b/arch/powerpc/include/asm/highmem.h
index dc1132c..0b4ac6a 100644
--- a/arch/powerpc/include/asm/highmem.h
+++ b/arch/powerpc/include/asm/highmem.h
@@ -38,7 +38,8 @@ extern pte_t *pkmap_page_table;
* easily, subsequent pte tables have to be allocated in one physical
* chunk of RAM.
*/
-#if defined(CONFIG_PPC_64K_PAGES) !defined(CONFIG_PPC64)
+#if defined(CONFIG_PPC_256K_PAGES) || \
+ (defined(CONFIG_PPC_64K_PAGES) !defined(CONFIG_PPC64))
#define PKMAP_ORDER(27 - PAGE_SHIFT)
#define LAST_PKMAP (1 PKMAP_ORDER)
#define PKMAP_BASE (FIXADDR_START - PAGE_SIZE*(LAST_PKMAP + 1))
diff --git a/arch/powerpc/include/asm/mmu-44x.h
b/arch/powerpc/include/asm/mmu-44x.h
index 2ca18e8..b943462 100644
--- a/arch/powerpc/include/asm/mmu-44x.h
+++ b/arch/powerpc/include/asm/mmu-44x.h
@@ -81,6 +81,8 @@ typedef struct {
#define PPC44x_TLBE_SIZE PPC44x_TLB_16K
#elif (PAGE_SHIFT == 16)
#define PPC44x_TLBE_SIZE PPC44x_TLB_64K
+#elif (PAGE_SHIFT == 18)
+#define PPC44x_TLBE_SIZE PPC44x_TLB_256K
#else
#error Unsupported PAGE_SIZE
#endif
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 537d5b1..f42c918 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -15,12 +15,14 @@
#include asm/types.h
/*
- * On regular PPC32 page size is 4K (but we support 4K/16K/64K pages
+ * On regular PPC32 page size is 4K (but we support 4K/16K/64K/256K pages
* on PPC44x). For PPC64 we support either 4K or 64K software
* page size. When using 64K pages however, whether we are really supporting
* 64K pages in HW or not is irrelevant to those definitions.
*/
-#if defined(CONFIG_PPC_64K_PAGES)
+#if defined(CONFIG_PPC_256K_PAGES)
+#define PAGE_SHIFT 18
+#elif defined(CONFIG_PPC_64K_PAGES)
#define PAGE_SHIFT 16
#elif defined(CONFIG_PPC_16K_PAGES)
#define PAGE_SHIFT 14
diff --git a/arch/powerpc/include/asm/page_32.h
b/arch/powerpc/include/asm/page_32.h
index ebfae53..273369a 100644
--- a/arch/powerpc/include/asm/page_32.h
+++ b/arch/powerpc/include/asm/page_32.h
@@ -20,7 +20,11 @@
*/
#ifdef CONFIG_PTE_64BIT
typedef unsigned long long pte_basic_t;
+#ifdef CONFIG_PPC_256K_PAGES
+#define PTE_SHIFT (PAGE_SHIFT - 7)
+#else
#define PTE_SHIFT (PAGE_SHIFT - 3)/* 512 ptes per page */
+#endif
#else
typedef unsigned long pte_basic_t;
#define PTE_SHIFT (PAGE_SHIFT - 2)/* 1024 ptes per page */
diff --git a/arch/powerpc/include/asm/thread_info.h
b/arch/powerpc/include/asm/thread_info.h
index 9665a26..3c8bbab 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -15,8 +15,12 @@
#ifdef CONFIG_PPC64
#define THREAD_SHIFT 14
#else
+#ifdef CONFIG_PPC_256K_PAGES
+#define THREAD_SHIFT 15
+#else
#define THREAD_SHIFT 13
#endif
+#endif
#define THREAD_SIZE(1 THREAD_SHIFT)
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index fce2df9..acd4b47 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -9,6 +9,13 @@
li r26,[EMAIL PROTECTED]; \
mtspr SPRN_IVOR##vector_number,r26; \
sync
+#ifndef CONFIG_PPC_256K_PAGES
+#define ALLOC_STACK_FRAME(reg, val)addireg,reg,val
+#else
+#define ALLOC_STACK_FRAME(reg, val)\
+ addis reg,reg,[EMAIL PROTECTED]; \
+ addireg,reg,[EMAIL PROTECTED]
+#endif
#define NORMAL_EXCEPTION_PROLOG
\
mtspr
[PATCH] powerpc: remove empty #else from signal_64.c
Remove empty/bogus #else from signal_64.c Signed-off-by: Michael Neuling [EMAIL PROTECTED] --- arch/powerpc/kernel/signal_64.c |2 -- 1 file changed, 2 deletions(-) Benh: Trivial cleanup patch for 2.6.28... diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c index 65ad925..c6a8f23 100644 --- a/arch/powerpc/kernel/signal_64.c +++ b/arch/powerpc/kernel/signal_64.c @@ -235,8 +235,6 @@ static long restore_sigcontext(struct pt_regs *regs, sigset_t *set, int sig, else for (i = 0; i 32 ; i++) current-thread.fpr[i][TS_VSRLOWOFFSET] = 0; - -#else #endif return err; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc allmodconfig
arch/powerpc/kernel/setup_64.c:447:5: warning: kernstart_addr is not defined arch/powerpc/kernel/setup_64.c:447:5: warning: kernstart_addr is not defined kernel/resource.c: In function '__reserve_region_with_split': kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t' kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t' kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t' kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'resource_size_t' sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026) sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026) lib/debugobjects.c:58: warning: 'obj_states' defined but not used net/dccp/options.c: In function 'dccp_parse_options': net/dccp/options.c:67: warning: 'value' may be used uninitialized in this function sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_write': sound/soc/codecs/tlv320aic23.c:104: warning: passing argument 2 of 'codec-hw_write' makes pointer from integer without a cast sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_set_dai_sysclk': sound/soc/codecs/tlv320aic23.c:424: warning: unused variable 'codec' drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios': drivers/dma/ioat_dca.c:81: error: implicit declaration of function 'cpuid_eax' drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled': drivers/dma/ioat_dca.c:91: error: implicit declaration of function 'boot_cpu_has' drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use in this function) drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported only once drivers/dma/ioat_dca.c:91: error: for each function it appears in.) drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag': drivers/dma/ioat_dca.c:190: error: implicit declaration of function 'cpu_physical_id' fs/ext4/balloc.c: In function 'ext4_claim_free_blocks': fs/ext4/balloc.c:607: warning: format '%lld' expects type 'long long int', but argument 2 has type 's64' fs/ext4/inode.c: In function 'ext4_print_free_blocks': fs/ext4/inode.c:1822: warning: format '%lld' expects type 'long long int', but argument 2 has type 's64' fs/ext4/inode.c:1824: warning: format '%lld' expects type 'long long int', but argument 2 has type 's64' net/sched/sch_generic.c: In function 'dev_watchdog': net/sched/sch_generic.c:224: warning: unused variable 'drivername' net/mac80211/rc80211_minstrel_debugfs.c: In function 'minstrel_stats_open': net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 11 has type 'u64' net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 12 has type 'u64' net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 11 has type 'u64' net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 12 has type 'u64' net/mac80211/rc80211_minstrel_debugfs.c: At top level: net/mac80211/rc80211_minstrel_debugfs.c:145: warning: initialization from incompatible pointer type drivers/ide/pci/scc_pata.c: In function 'init_hwif_scc': drivers/ide/pci/scc_pata.c:846: warning: unused variable 'ports' drivers/ide/pci/hpt366.c: In function 'init_hwif_hpt366': drivers/ide/pci/hpt366.c:1292: warning: unused variable 'dev' include/linux/ucb1400.h:139: warning: 'ucb1400_adc_read' defined but not used drivers/mtd/devices/docprobe.c:80:2: warning: #warning Unknown architecture for DiskOnChip. No default probe locations defined fs/ocfs2/xattr.c: In function 'ocfs2_xattr_index_block_find': fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64' fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64' fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64' fs/ocfs2/xattr.c: In function 'ocfs2_iterate_xattr_buckets': fs/ocfs2/xattr.c:2424: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64' fs/ocfs2/xattr.c:2424: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64' fs/ocfs2/xattr.c:2424: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64' fs/ocfs2/xattr.c:2443: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'u64' fs/ocfs2/xattr.c:2443: warning: format '%llu' expects type 'long long unsigned
Re: powerpc allmodconfig
Some comments for some of these... On Wed, 2008-10-15 at 21:33 -0700, Andrew Morton wrote: kernel/resource.c: In function '__reserve_region_with_split': kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t' kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t' kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t' kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'resource_size_t' This is a generic code bug, I sent a patch for it a day or two ago. (ie those are real bugs on 32-bit resource_size_t) drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios': drivers/dma/ioat_dca.c:81: error: implicit declaration of function 'cpuid_eax' drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled': drivers/dma/ioat_dca.c:91: error: implicit declaration of function 'boot_cpu_has' drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use in this function) drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported only once drivers/dma/ioat_dca.c:91: error: for each function it appears in.) drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag': drivers/dma/ioat_dca.c:190: error: implicit declaration of function 'cpu_physical_id' Looks like this driver should depend on X86 :-) fs/ext4/balloc.c: In function 'ext4_claim_free_blocks': fs/ext4/balloc.c:607: warning: format '%lld' expects type 'long long int', but argument 2 has type 's64' fs/ext4/inode.c: In function 'ext4_print_free_blocks': fs/ext4/inode.c:1822: warning: format '%lld' expects type 'long long int', but argument 2 has type 's64' fs/ext4/inode.c:1824: warning: format '%lld' expects type 'long long int', but argument 2 has type 's64' The above are unfortunate but at least aren't bugs per-se, just annoying. Should be fixable with casts. Ted ? net/mac80211/rc80211_minstrel_debugfs.c: In function 'minstrel_stats_open': net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 11 has type 'u64' net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 12 has type 'u64' net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 11 has type 'u64' net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects type 'long long unsigned int', but argument 12 has type 'u64' net/mac80211/rc80211_minstrel_debugfs.c: At top level: net/mac80211/rc80211_minstrel_debugfs.c:145: warning: initialization from incompatible pointer type Same. fs/ocfs2/xattr.c: In function 'ocfs2_xattr_index_block_find': fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64' fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned int', but argument 7 has type 'u64' .../... same sound/pci/hda/patch_sigmatel.c: In function 'stac92xx_parse_auto_config': sound/pci/hda/patch_sigmatel.c:2819: warning: 'nid' may be used uninitialized in this function drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_read': drivers/rtc/rtc-ds1286.c:33: error: implicit declaration of function '__raw_readl' drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_write': drivers/rtc/rtc-ds1286.c:38: error: implicit declaration of function '__raw_writel' drivers/rtc/rtc-ds1286.c: In function 'ds1286_probe': drivers/rtc/rtc-ds1286.c:345: error: implicit declaration of function 'ioremap' drivers/rtc/rtc-ds1286.c:345: warning: assignment makes pointer from integer without a cast drivers/rtc/rtc-ds1286.c:365: error: implicit declaration of function 'iounmap' make[2]: [drivers/rtc/rtc-ds1286.o] Error 1 (ignored) Missing #include asm/io.h ? drivers/rtc/rtc-m48t35.c: In function 'm48t35_read_time': drivers/rtc/rtc-m48t35.c:59: error: implicit declaration of function 'readb' drivers/rtc/rtc-m48t35.c:60: error: implicit declaration of function 'writeb' drivers/rtc/rtc-m48t35.c: In function 'm48t35_probe': drivers/rtc/rtc-m48t35.c:168: error: implicit declaration of function 'ioremap' drivers/rtc/rtc-m48t35.c:168: warning: assignment makes pointer from integer without a cast drivers/rtc/rtc-m48t35.c:188: error: implicit declaration of function 'iounmap' Same ? drivers/net/ibm_newemac/mal.c: In function 'mal_txeob': drivers/net/ibm_newemac/mal.c:284: error: implicit declaration of function 'mtdcri' drivers/net/ibm_newemac/mal.c:284: error: 'SDR0' undeclared (first use in this function) drivers/net/ibm_newemac/mal.c:284: error: (Each undeclared identifier is reported only once drivers/net/ibm_newemac/mal.c:284: error: for each
Re: powerpc allmodconfig
From: Andrew Morton [EMAIL PROTECTED] Date: Wed, 15 Oct 2008 21:33:37 -0700 kernel/resource.c: In function '__reserve_region_with_split': kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t' kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t' kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t' kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'resource_size_t' Known issue, Ben wants to add a new variant of %pX in order to print resources so that resource_size_t vs. unsigned long stuff doesn't matter like this any more. net/dccp/options.c: In function 'dccp_parse_options': net/dccp/options.c:67: warning: 'value' may be used uninitialized in this function Known issue, not trivial to fix, gcc is just being incredibly silly here as it can't see all of the control flow. drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios': drivers/dma/ioat_dca.c:81: error: implicit declaration of function 'cpuid_eax' drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled': drivers/dma/ioat_dca.c:91: error: implicit declaration of function 'boot_cpu_has' drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use in this function) drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported only once drivers/dma/ioat_dca.c:91: error: for each function it appears in.) drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag': drivers/dma/ioat_dca.c:190: error: implicit declaration of function 'cpu_physical_id' Known issue. I tried to ping Jeff Garzik about doing a driver bug fix run in order to fix this, but he hasn't shown any signs of life. So I'll do it myself later tonight. :-/ net/sched/sch_generic.c: In function 'dev_watchdog': net/sched/sch_generic.c:224: warning: unused variable 'drivername' Sucky, if WARN_ONCE() evaluates to nothing the sprintf() string buffer on the stack looks unused. drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_read': drivers/rtc/rtc-ds1286.c:33: error: implicit declaration of function '__raw_readl' drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_write': drivers/rtc/rtc-ds1286.c:38: error: implicit declaration of function '__raw_writel' drivers/rtc/rtc-ds1286.c: In function 'ds1286_probe': drivers/rtc/rtc-ds1286.c:345: error: implicit declaration of function 'ioremap' drivers/rtc/rtc-ds1286.c:345: warning: assignment makes pointer from integer without a cast drivers/rtc/rtc-ds1286.c:365: error: implicit declaration of function 'iounmap' Missing asm/io.h include. drivers/rtc/rtc-m48t35.c: In function 'm48t35_read_time': drivers/rtc/rtc-m48t35.c:59: error: implicit declaration of function 'readb' drivers/rtc/rtc-m48t35.c:60: error: implicit declaration of function 'writeb' drivers/rtc/rtc-m48t35.c: In function 'm48t35_probe': drivers/rtc/rtc-m48t35.c:168: error: implicit declaration of function 'ioremap' drivers/rtc/rtc-m48t35.c:168: warning: assignment makes pointer from integer without a cast drivers/rtc/rtc-m48t35.c:188: error: implicit declaration of function 'iounmap' Likewise. drivers/net/wireless/libertas_tf/if_usb.c: In function '__if_usb_submit_rx_urb': drivers/net/wireless/libertas_tf/if_usb.c:334: warning: cast to pointer from integer of different size I've seen this one on sparc64 too, I think the arg is totally unused in the end for this callback control flow and we can just use NULL or zero instead. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problems with PCI-E devices not being detected with switch
On Wed, 2008-10-15 at 10:47 -0500, Ayman El-Khashab wrote: Note for people on CC: This is a problem on 460EX on a canyonland using the 4x port. The problem occurs when Linux boots. It sees the switch (and looking in /sys/bus/... confirms it), but nothing on the downstream sides of the switch (secondary busses) is visible. There were no boot messages to indicate it had seen the Sil 3531 and it doesn't function. We've also tried other PCI-E devices (NI GPIB) on the downstream side and they are also not detected, so it seems to be something in Linux, my configuration, etc. I've included the boot messages below from u-boot and the kernel. It is more than just the pci boot messages, but I was not sure if something else in the log with provide some insight. The messages below look really fishy indeed: pci 0001:02:00.0: unknown header type 03, ignoring device pci 0001:02:01.0: unknown header type 41, ignoring device pci 0001:02:02.0: unknown header type 03, ignoring device pci 0001:02:03.0: unknown header type 41, ignoring device pci 0001:02:04.0: ignoring class 1d09 (doesn't match header type 02) pci 0001:02:05.0: unknown header type 41, ignoring device pci 0001:02:06.0: ignoring class 1d09 (doesn't match header type 02) pci 0001:02:07.0: unknown header type 41, ignoring device pci 0001:02:08.0: unknown header type 03, ignoring device pci 0001:02:09.0: unknown header type 41, ignoring device pci 0001:02:0a.0: ignoring class 7d09 (doesn't match header type 02) pci 0001:02:0b.0: unknown header type 41, ignoring device pci 0001:02:0c.0: ignoring class 1d01 (doesn't match header type 02) pci 0001:02:0d.0: unknown header type 41, ignoring device pci 0001:02:0e.0: ignoring class 7d09 (doesn't match header type 02) pci 0001:02:0f.0: unknown header type 41, ignoring device pci 0001:02:10.0: unknown header type 03, ignoring device pci 0001:02:11.0: unknown header type 41, ignoring device pci 0001:02:12.0: unknown header type 03, ignoring device pci 0001:02:13.0: unknown header type 41, ignoring device pci 0001:02:14.0: unknown header type 03, ignoring device pci 0001:02:15.0: unknown header type 41, ignoring device pci 0001:02:16.0: ignoring class 3d09 (doesn't match header type 02) pci 0001:02:17.0: unknown header type 41, ignoring device pci 0001:02:18.0: unknown header type 03, ignoring device pci 0001:02:19.0: unknown header type 41, ignoring device pci 0001:02:1a.0: unknown header type 03, ignoring device pci 0001:02:1b.0: unknown header type 41, ignoring device pci 0001:02:1c.0: ignoring class 5d01 (doesn't match header type 02) pci 0001:02:1d.0: unknown header type 41, ignoring device pci 0001:02:1e.0: unknown header type 03, ignoring device pci 0001:02:1f.0: unknown header type 41, ignoring device Stefan, do you reckon it could be that we aren't leaving enough time for the things behind the switch to initialize ? Or could there be a subtle kernel bug here ? It looks to me that config space access behind the switch is broken. Ayman, can you try adding a long delay (such as msleep(5000), ie 5s) at the beginning of pcibios_init() in arch/powerpc/kernel/pci_32.c ? This will add 5s delay between the init/reset of the port and the probing by linux. Do that help ? Stefan, shouldn't we find a nice way to avoid the whole port reset and reconfiguration of the HW also when uboot already did a good enough job, maybe via some device-tree property ? It would also significantly speed up boot times. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allmodconfig
On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote: From: Andrew Morton [EMAIL PROTECTED] Date: Wed, 15 Oct 2008 21:33:37 -0700 kernel/resource.c: In function '__reserve_region_with_split': kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'resource_size_t' kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'resource_size_t' kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t' kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned int', but argument 7 has type 'resource_size_t' Known issue, Ben wants to add a new variant of %pX in order to print resources so that resource_size_t vs. unsigned long stuff doesn't matter like this any more. Actually, I was told Linus had one and I've been trying to dig it out... Oh well, I may as well dig my own old one. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allmodconfig
At Wed, 15 Oct 2008 21:33:37 -0700, Andrew Morton wrote: sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026) sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026) These are definitions of deprecated interfaces. We can remove it in 2.6.29. If we don't want to be conservative, it can be removed in 2.6.28, too. sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_write': sound/soc/codecs/tlv320aic23.c:104: warning: passing argument 2 of 'codec-hw_write' makes pointer from integer without a cast sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_set_dai_sysclk': sound/soc/codecs/tlv320aic23.c:424: warning: unused variable 'codec' The fix was in the pending pull request. sound/pci/hda/patch_sigmatel.c: In function 'stac92xx_parse_auto_config': sound/pci/hda/patch_sigmatel.c:2819: warning: 'nid' may be used uninitialized in this function Ditto. thanks, Takashi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
