Re: [PATCH] ALPHA: support graphics on non-zero PCI domains (take 2)
Sam Ravnborg wrote:
+#ifndef CONFIG_ALPHA_GENERIC
+EXPORT_SYMBOL(tsunami_ioportmap);
+EXPORT_SYMBOL(tsunami_ioremap);
+#endif
>>> It looks strange that the function is always defined but conditionally
>>> exported.
>>> Also usual style is to place EXPORT right after closing brace of function -
>>> (with no empty lines in-between).
>> In a generic kernel the IO functions are never addressed directly,
>> only via machine vector, so there is no point in exporting them.
>> What about something like EXPORT_SYMBOL_NONGENERIC() macro?
> As I wrote it looked strange. Unconditionally exporting them should not harm
> and then we are one pair of ifdef/endif shorter?
>
> Nitty gritty detail so do what you think match best.
>
> Sam
Thanks for all the feedback, Sam.
Find attached a reworked set of patches that I think cleans up all the
areas with which you had issues.
Sorry about putting it into an attachment, I've yet to figure out out
to do the verbatim inclusion of patch text into Thunderbird without
adverse side effects... :-(
Thanks again.
--Jay++
--
Jay A EstabrookHPTC - XC I & B
Hewlett-Packard Company - ZKO1-3/D-B.8 (603) 884-0301
110 Spit Brook Road, Nashua NH 03062 [EMAIL PROTECTED]
diff -Naurp a/arch/alpha/Kconfig c/arch/alpha/Kconfig
--- a/arch/alpha/Kconfig2007-04-02 13:03:21.0 -0400
+++ c/arch/alpha/Kconfig2007-04-15 14:03:24.0 -0400
@@ -481,6 +481,15 @@ config ALPHA_BROKEN_IRQ_MASK
depends on ALPHA_GENERIC || ALPHA_PC164
default y
+config VGA_HOSE
+ bool
+ depends on ALPHA_GENERIC || ALPHA_TITAN || ALPHA_MARVEL || ALPHA_TSUNAMI
+ default y
+ help
+ Support VGA on an arbitrary hose; needed for several platforms
+ which always have multiple hoses, and whose consoles support it.
+
+
config ALPHA_SRM
bool "Use SRM as bootloader" if ALPHA_CABRIOLET || ALPHA_AVANTI_CH ||
ALPHA_EB64P || ALPHA_PC164 || ALPHA_TAKARA || ALPHA_EB164 || ALPHA_ALCOR ||
ALPHA_MIATA || ALPHA_LX164 || ALPHA_SX164 || ALPHA_NAUTILUS || ALPHA_NONAME
default y if ALPHA_JENSEN || ALPHA_MIKASA || ALPHA_SABLE || ALPHA_LYNX
|| ALPHA_NORITAKE || ALPHA_DP264 || ALPHA_RAWHIDE || ALPHA_EIGER ||
ALPHA_WILDFIRE || ALPHA_TITAN || ALPHA_SHARK || ALPHA_MARVEL
@@ -644,6 +653,13 @@ source "arch/alpha/oprofile/Kconfig"
source "arch/alpha/Kconfig.debug"
+# DUMMY_CONSOLE may be defined in drivers/video/console/Kconfig
+# but we also need it if VGA_HOSE is set
+config DUMMY_CONSOLE
+ bool
+ depends on VGA_HOSE
+ default y
+
source "security/Kconfig"
source "crypto/Kconfig"
diff -Naurp a/arch/alpha/kernel/console.c c/arch/alpha/kernel/console.c
--- a/arch/alpha/kernel/console.c 2007-02-04 13:44:54.0 -0500
+++ c/arch/alpha/kernel/console.c 2007-04-15 12:27:37.0 -0400
@@ -9,16 +9,20 @@
#include
#include
#include
+#include
#include
#include
+#include "pci_impl.h"
+
#ifdef CONFIG_VGA_HOSE
-/*
- * Externally-visible vga hose bases
- */
-unsigned long __vga_hose_io_base = 0; /* base for default hose */
-unsigned long __vga_hose_mem_base = 0; /* base for default hose */
+struct pci_controller *pci_vga_hose = NULL;
+static struct resource alpha_vga = {
+ .name = "alpha-vga+",
+ .start = 0x3C0,
+ .end= 0x3DF
+};
static struct pci_controller * __init
default_vga_hose_select(struct pci_controller *h1, struct pci_controller *h2)
@@ -30,36 +34,58 @@ default_vga_hose_select(struct pci_contr
}
void __init
-set_vga_hose(struct pci_controller *hose)
-{
- if (hose) {
- __vga_hose_io_base = hose->io_space->start;
- __vga_hose_mem_base = hose->mem_space->start;
- }
-}
-
-void __init
locate_and_init_vga(void *(*sel_func)(void *, void *))
{
struct pci_controller *hose = NULL;
struct pci_dev *dev = NULL;
+ /* Default the select function */
if (!sel_func) sel_func = (void *)default_vga_hose_select;
+ /* Find the console VGA device */
for(dev=NULL; (dev=pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, dev));) {
- if (!hose) hose = dev->sysdata;
- else hose = sel_func(hose, dev->sysdata);
+ if (!hose)
+ hose = dev->sysdata;
+ else
+ hose = sel_func(hose, dev->sysdata);
}
- /* Did we already inititialize the correct one? */
- if (conswitchp == &vga_con &&
- __vga_hose_io_base == hose->io_space->start &&
- __vga_hose_mem_base == hose->mem_space->start)
+ /* Did we already initialize the correct one? Is there one? */
+ if (!hose || (conswitchp == &vga_con && pci_vga_hose == hose))
return;
- /* Set the VGA hose and init the new console */
- set_vga_hose(hose);
+ /* Create a new VGA ioport resource WRT the hose it is on. */
+
Re: [PATCH 7/7] ALPHA: support graphics on non-zero PCI domains
Richard Henderson wrote:
On Wed, Apr 11, 2007 at 12:30:48PM +0400, Ivan Kokshaysky wrote:
+VGA_MAP_MEM(unsigned long xaddr, unsigned int size)
+{
+ /* Create a new VGA ioport resource WRT the hose it is on. */
+ if (pci_vga_hose && pci_vga_hose->index) {
+ static struct resource alpha_vga =
+ { .name = "alpha-vga+", .start = 0x3C0, .end = 0x3DF };
+ struct resource new_vga = alpha_vga;
+
+ new_vga.start += pci_vga_hose->io_space->start;
+ new_vga.end += pci_vga_hose->io_space->start;
+ request_resource(&ioport_resource, &new_vga);
This leaks the local stack frame variable new_vga into the
resource tree, does it not? Shouldn't you be kmallocing this?
r~
Yes, it does leak, and yes, it should be kmalloced. Something like this?
struct resource *new_vga;
new_vga = kmalloc(sizeof(struct resource), GFP_ATOMIC);
if (new_vga) {
*new_vga = alpha_vga;
new_vga->start += pci_vga_hose->io_space->start;
new_vga->end += pci_vga_hose->io_space->start;
request_resource(&ioport_resource, new_vga);
}
Thanks, Richard, I'll regenerate this one...
--Jay++
--
Jay A EstabrookHPTC - XC I & B
Hewlett-Packard Company - ZKO1-3/D-B.8 (603) 884-0301
110 Spit Brook Road, Nashua NH 03062 [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: alpha/2.4.x: CPU misdetection, possible miscompilation
On Thu, May 17, 2001 at 02:23:03PM +0200, Michael Wildpaner wrote: > > trying to boot any 2.4.x kernel on a Tsunami DP264 alpha with dual EV67, > we found the following problems: > > CPU misdetection: > > On our machine the cpu->type field contains 0x8000B > (= 2^35 + 11) instead of 0xB (= hwrpb.h: #define EV67_CPU 11). > > The spurious high bit leads to false/default values for > on_chip_cache in smp.c:smp_tune_scheduling. >... >+/* mask for cpu->type (arbitrary assumption based on #define's in hwrpb.h) */ >+#define CPU_TYPE_MASK 0xFF >... >- switch (cpu->type) >+ switch (cpu->type & CPU_TYPE_MASK) The Alpha Architecture Reference Manual describes the PROCESSOR TYPE field of the per-CPU slot HWRPB information, as: bitsinterpretation -- 63-32 minor type 31-0major type so the above patch should have CPU_TYPE_MASK as 0x (optimistic :-); or you could just: switch ((unsigned int) cpu->type) like the /proc/cpuinfo printing code in setup.c does. The "minor type" is usually a reference to the "pass" number of the chip, and can be ignored. --Jay++ - Jay A EstabrookAlpha Engineering - LINUX Project Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080 200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED] - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre6 on alpha
On Wed, Dec 06, 2000 at 08:47:23PM -0500, Wakko Warner wrote: > I'm glad to say that this is the first 2.4 kernel that works on my noritake > alpha with a pci-pci bridge. > > I have a small problem. If I reboot, the srm console can't boot from dka0. > Doing a: show dev > doesn't list any of the hard drives in the machine. > doing an init causes it to reset and find all the drives again. During boot, the Linux kernel code (on Alpha) changes the PCI resource settings of cards and bridges alike. Some SRM consoles do not appreciate this... ;-} There is code in 2.2 that restores card/bridge settings before exiting the kernel back to console mode. This code has NOT been ported to 2.4, due primarily to the size of the changes made to 2.4 in that area. Could you verify that 2.2 (take the latest, please) DOES exit to SRM correctly? A workaround for 2.4 is to set "boot_reset" to ON in SRM, which will force a full reset before continuing the boot. Yes, I know, for a lot of situations this is overkill, but at least it will do the right thing under the above described situations... Good luck. --Jay++ - Jay A EstabrookAlpha Engineering - LINUX Project Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080 200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED] - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha SCSI error on 2.4.0-test11
On Mon, Dec 04, 2000 at 01:53:42PM -0500, Phillip Ezolt wrote:
>
> I've recompiled as you have suggested. Any ideas?
Compile again with the following patches (these are against 2.4.0-test12,
but those in arch/alpha/kernel/core_cia.c should work against test10/11
as well).
Something got lost between 2.2 and 2.4, but it's most likely that
MIATA (because it has 6 DIMM slots) is one of the few CIA and PYXIS
machines that could actually get over 1GB of memory; that's why we
haven't seen this before...
--Jay++
-
Jay A EstabrookAlpha Engineering - LINUX Project
Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080
200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED]
-
diff -urN old/arch/alpha/kernel/core_cia.c new/arch/alpha/kernel/core_cia.c
--- old/arch/alpha/kernel/core_cia.cTue Dec 5 10:09:01 2000
+++ new/arch/alpha/kernel/core_cia.cTue Dec 5 18:45:12 2000
@@ -700,11 +700,11 @@
*(vip)CIA_IOC_PCI_W1_BASE = 0x4000 | 1;
*(vip)CIA_IOC_PCI_W1_MASK = (0x4000 - 1) & 0xfff0;
- *(vip)CIA_IOC_PCI_T1_BASE = 0;
+ *(vip)CIA_IOC_PCI_T1_BASE = 0 >> 2;
*(vip)CIA_IOC_PCI_W2_BASE = 0x8000 | 1;
*(vip)CIA_IOC_PCI_W2_MASK = (0x4000 - 1) & 0xfff0;
- *(vip)CIA_IOC_PCI_T2_BASE = 0x4000;
+ *(vip)CIA_IOC_PCI_T2_BASE = 0x4000 >> 2;
*(vip)CIA_IOC_PCI_W3_BASE = 0;
}
diff -urN old/arch/alpha/kernel/pci.c new/arch/alpha/kernel/pci.c
--- old/arch/alpha/kernel/pci.c Tue Dec 5 10:09:01 2000
+++ new/arch/alpha/kernel/pci.c Tue Dec 5 10:20:01 2000
@@ -91,9 +91,15 @@
if (dev->class >> 8 != PCI_CLASS_STORAGE_IDE)
return;
dev->resource[1].start |= 2;
- dev->resource[1].end = dev->resource[1].start;
+ dev->resource[1].end = dev->resource[1].start + 1;
+#ifndef CONFIG_BLK_DEV_IDEPCI
+ /* already claimed by "standard" (ie junk) resources */
+ dev->resource[0].flags &= ~IORESOURCE_IO;
+ dev->resource[1].flags &= ~IORESOURCE_IO;
+#else
pci_claim_resource(dev, 0);
pci_claim_resource(dev, 1);
+#endif
}
static void __init
diff -urN old/drivers/pci/pci.c new/drivers/pci/pci.c
--- old/drivers/pci/pci.c Tue Dec 5 10:09:02 2000
+++ new/drivers/pci/pci.c Tue Dec 5 10:17:32 2000
@@ -540,7 +540,7 @@
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int rom)
{
unsigned int pos, reg, next;
- u32 l, sz;
+ u32 l, sz, tmp;
struct resource *res;
for(pos=0; poshttp://www.tux.org/lkml/
Re: test9-pre9
On Tue, Oct 03, 2000 at 11:07:36AM +0900, Tom Holroyd wrote: > Alpha DP264 (UP) > > ld ... -o vmlinux > drivers/char/char.o: In function `rs_sched_event': > serial.c(.text+0x10210): undefined reference to `barrier' > serial.c(.text+0x10214): undefined reference to `barrier' > serial.c(.text+0x1022c): undefined reference to `barrier' > serial.c(.text+0x10230): undefined reference to `barrier' > serial.c(.text+0x10244): undefined reference to `barrier' > drivers/char/char.o(.text+0x10248):serial.c: more undefined references to > `barrier' follow > > config attached. > > This error existed in -pre8, too, but I sent the message to rutgers... As suggested days ago by Ivan, one solution is: - diff -urN old/include/asm-alpha/bitops.h new/include/asm-alpha/bitops.h --- old/include/asm-alpha/bitops.h Mon Oct 2 21:50:50 2000 +++ new/include/asm-alpha/bitops.h Mon Oct 2 22:38:25 2000 @@ -2,6 +2,7 @@ #define _ALPHA_BITOPS_H #include +#include /* * Copyright 1994, Linus Torvalds. - SMP compiles fine with or without this. --Jay++ - Jay A EstabrookAlpha Engineering - LINUX Project Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080 200 Forest Street, Marlboro MA 01752 [EMAIL PROTECTED] - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
