- 07 2月, 2006 1 次提交
-
-
由 Michael Ellerman 提交于
arch/powerpc/kernel/rtas.c is getting hvcall.h via spinlock.h, but when we're building for UP we don't include spinlock.h. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 14 1月, 2006 1 次提交
-
-
由 Dave C Boutcher 提交于
Handle the ibm,suspend-me RTAS call specially. It needs to be wrapped in a set of synchronization hypervisor calls (H_Join). When the H_Join calls are made on all CPUs, the intent is that only one will return with H_Continue, meaning that he is the "last man standing". That CPU then issues the ibm,suspend-me call. What is interesting, of course, is that the CPU running when the rtas syscall is made, may NOT be the CPU that ultimately executes the ibm,suspend-me rtas call. Signed-off-by: NDave Boutcher <sleddog@us.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 12 1月, 2006 1 次提交
-
-
由 Randy Dunlap 提交于
arch: Use <linux/capability.h> where capable() is used. Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 11 1月, 2006 1 次提交
-
-
由 Michael Ellerman 提交于
This patch adds Kconfig entries to control the early debugging options, currently in setup_64.c. Doing this via Kconfig rather than #defines means you can have one source tree, which is buildable for multiple platforms - and you can enable the correct early debug option for each platform via .config. I made udbg_early_init() a static inline because otherwise GCC is to daft to optimise it away when debugging is off. Now that we have udbg_init_rtas() we can make call_rtas_display_status* static. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 10 1月, 2006 1 次提交
-
-
由 Adrian Bunk 提交于
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 10 11月, 2005 1 次提交
-
-
由 Paul Mackerras 提交于
This patch merges platform codes. systemcfg->platform is no longer used, systemcfg use in general is deprecated as much as possible (and renamed _systemcfg before it gets completely moved elsewhere in a future patch), _machine is now used on ppc64 along as ppc32. Platform codes aren't gone yet but we are getting a step closer. A bunch of asm code in head[_64].S is also turned into C code. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 08 11月, 2005 1 次提交
-
-
由 Benjamin Herrenschmidt 提交于
Building a PowerMac kernel with ARCH=powerpc causes a bunch of warnings, this fixes some of them Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 07 11月, 2005 1 次提交
-
-
由 Paul Mackerras 提交于
Mostly this involves adding #include <asm/smp.h>, since that defines things like boot_cpuid[_phys] and [gs]et_hard_smp_processor_id, which are SMP-related but still needed on UP. This incorporates fixes posted by Olof Johansson and Heikki Lindholm. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 03 11月, 2005 1 次提交
-
-
由 Paul Mackerras 提交于
This moves rtas-proc.c and rtas_flash.c into arch/powerpc/kernel, since cell wants them as well as pseries (and chrp can use rtas-proc.c too, at least in principle). rtas_fw.c is gone, with its bits moved into rtas_flash.c and rtas.c. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 26 10月, 2005 1 次提交
-
-
由 Paul Mackerras 提交于
This splits arch/ppc64/kernel/rtas.c into arch/powerpc/kernel/rtas.c, which contains generic RTAS functions useful on any CHRP platform, and arch/powerpc/platforms/pseries/rtas-fw.[ch], which contain some pSeries-specific firmware flashing bits. The parts of rtas.c that are to do with pSeries-specific error logging are protected by a new CONFIG_RTAS_ERROR_LOGGING symbol. The inclusion of rtas.o is controlled by the CONFIG_PPC_RTAS symbol, and the relevant platforms select that. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 10 10月, 2005 1 次提交
-
-
由 Paul Mackerras 提交于
In preparation for merging processor.h, this adds some explicit but won't be after the merge. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 23 6月, 2005 2 次提交
-
-
由 Mike Strosaker 提交于
This patch corrects the printing of progress indicators to the op panel on p/iSeries ppc64 systems. Each discrete reference code should begin with a form feed char to clear the op panel, and the first and second lines should be separated with a CR/LF sequence. Padding with spaces is not necessary. Also, capitalize the hex value printed on the first line, to be consistent with the values printed by firmware, service processor, etc. It turns out that there's an ibm,form-feed property; this patch uses it in the pSeries-specific progress routine. This patch also checks the number of rows and the specific width of each row (the second row on power5 systems can actually hold 80 characters). If the displayed text is too wide for the physical display, it can be viewed in the ASM menus, or by selecting option 14 on the op panel. Signed-off-by: NMike Strosaker <strosake@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Arnd Bergmann 提交于
The pSeries_progress function is called from some places in the rtas code, which may also be used by non-pSeries platforms. Though pSeries is currently the only platform type that implements display-character, the code is actually generic enough to be part of the rtas subsystem. I hit a bug here because the generic rtas code tried calling ppc_md.progress, which points to an __init function on most platforms. We could also clear the ppc_md.progress pointer when freeing the init memory to make it more explicit that ppc_md.progress must not be called after bootup. Signed-off-by: NArnd Bergmann <arndb@de.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-