aboutsummaryrefslogtreecommitdiff
path: root/arch/sparc/prom
AgeCommit message (Collapse)Author
2008-05-20sparc: remove CVS keywordsAdrian Bunk
This patch removes the CVS keywords that weren't updated for a long time from comments. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-05-02sparc32: Delete prom_stdin and prom_stdout.David S. Miller
They are written, but never used. Signed-off-by: David S. Miller <davem@davemloft.net>
2008-05-02sparc32: More memory probing consolidation.David S. Miller
The PROM library function prom_meminit() builds a table, prom_phys_avail[], just so that probe_memory() in arch/sparc/mm/fault.c can copy it into sp_banks[]. Just have prom_meminit() fill in the sp_banks[] array directly, and remove duplicated sort() function. Signed-off-by: David S. Miller <davem@davemloft.net>
2008-05-02sparc32: Kill totally unused memory information tables.David S. Miller
The code in arch/sparc/prom/memory.c computes three tables, the list of total memory, the list of available memory (total minus what firmware is using), and the list of firmware taken memory. Only the available memory list is even used. Therefore, kill those unused tables and make prom_meminfo() return just the available memory list. Signed-off-by: David S. Miller <davem@davemloft.net>
2008-02-18[SPARC]: Kill 'prom_palette'.David S. Miller
The idea of this thing is we could save/restore the firmware's palette when breaking in and out of the firmware prompt. Only one driver implemented this (atyfb) and it's value is questionable. If you're just debugging you don't really care that the characters end up being purple or whatever. And we can provide better debugging and firmware command facilities with minimal in-kernel console I/O drivers. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-08-26[SPARC32]: Kill unused vars and macros from prom/console.cDavid S. Miller
This should have been removed during the of_console_device changes. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-07-24[SPARC32]: missing exportsAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-07-20[SPARC]: Fix serial console device detection.David S. Miller
The current scheme works on static interpretation of text names, which is wrong. The output-device setting, for example, must be resolved via an alias or similar to a full path name to the console device. Paths also contain an optional set of 'options', which starts with a colon at the end of the path. The option area is used to specify which of two serial ports ('a' or 'b') the path refers to when a device node drives multiple ports. 'a' is assumed if the option specification is missing. This was caught by the UltraSPARC-T1 simulator. The 'output-device' property was set to 'ttya' and we didn't pick upon the fact that this is an OBP alias set to '/virtual-devices/console'. Instead we saw it as the first serial console device, instead of the hypervisor console. The infrastructure is now there to take advantage of this to resolve the console correctly even in multi-head situations in fbcon too. Thanks to Greg Onufer for the bug report. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-05-11[SPARC]: Spelling fixes.Simon Arlott
Spelling fixes in arch/sparc/. Signed-off-by: Simon Arlott <simon@fire.lp0.eu> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-07-21[SPARC]: Kill prom_getname, unused and not implemented properly.David S. Miller
The m68k port's sun3 asm/oplib.h had a stray reference too, so I killed that off as well. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2005-05-04[PATCH] sparc NULL noise removalAl Viro
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus 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!