All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: sparc32 git tree
@ 2006-07-17 15:45 Bob Breuer
  2006-07-17 17:57 ` Raymond Burns
                   ` (11 more replies)
  0 siblings, 12 replies; 13+ messages in thread
From: Bob Breuer @ 2006-07-17 15:45 UTC (permalink / raw)
  To: sparclinux

[-- Attachment #1: Type: text/plain, Size: 207 bytes --]

Ray,

I think I've found the core problem with the prom properties, and a
potential problem with the zilog initialization.  Could you try the
attached patch and let me know if it works for you?

Thanks,
Bob

[-- Attachment #2: sparc32-fix_prom_probing.txt --]
[-- Type: text/plain, Size: 2126 bytes --]

diff --git a/arch/sparc/kernel/prom.c b/arch/sparc/kernel/prom.c
index 4b06dcb..4ca9e5f 100644
--- a/arch/sparc/kernel/prom.c
+++ b/arch/sparc/kernel/prom.c
@@ -444,6 +444,7 @@ static struct property * __init build_on
 	static struct property *tmp = NULL;
 	struct property *p;
 	int len;
+	const char *name;
 
 	if (tmp) {
 		p = tmp;
@@ -456,19 +457,21 @@ static struct property * __init build_on
 
 	p->name = (char *) (p + 1);
 	if (special_name) {
+		strcpy(p->name, special_name);
 		p->length = special_len;
 		p->value = prom_early_alloc(special_len);
 		memcpy(p->value, special_val, special_len);
 	} else {
 		if (prev == NULL) {
-			prom_firstprop(node, p->name);
+			name = prom_firstprop(node, NULL);
 		} else {
-			prom_nextprop(node, prev, p->name);
+			name = prom_nextprop(node, prev, NULL);
 		}
-		if (strlen(p->name) == 0) {
+		if (strlen(name) == 0) {
 			tmp = p;
 			return NULL;
 		}
+		strcpy(p->name, name);
 		p->length = prom_getproplen(node, p->name);
 		if (p->length <= 0) {
 			p->length = 0;
diff --git a/drivers/serial/sunzilog.c b/drivers/serial/sunzilog.c
index a1456d9..b88f7de 100644
--- a/drivers/serial/sunzilog.c
+++ b/drivers/serial/sunzilog.c
@@ -524,7 +524,6 @@ static irqreturn_t sunzilog_interrupt(in
 {
 	struct uart_sunzilog_port *up = dev_id;
 
-	while (up) {
 		struct zilog_channel __iomem *channel
 			= ZILOG_CHANNEL_FROM_PORT(&up->port);
 		struct tty_struct *tty;
@@ -575,9 +574,6 @@ static irqreturn_t sunzilog_interrupt(in
 		if (tty)
 			tty_flip_buffer_push(tty);
 
-		up = up->next;
-	}
-
 	return IRQ_HANDLED;
 }
 
@@ -1352,18 +1348,17 @@ static int __devinit zs_probe(struct of_
 
 	rp = sunzilog_chip_regs[inst];
 
-	if (zilog_irq == -1) {
+	up = &sunzilog_port_table[inst * 2];
+	//if (zilog_irq == -1) {
 		zilog_irq = op->irqs[0];
 		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,
-				  "zs", sunzilog_irq_chain);
+				  "zs", up);
 		if (err) {
 			of_iounmap(rp, sizeof(struct zilog_layout));
 
 			return err;
 		}
-	}
-
-	up = &sunzilog_port_table[inst * 2];
+	//}
 
 	/* Channel A */
 	up[0].port.mapbase = op->resource[0].start + 0x00;

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: sparc32 git tree
  2006-07-17 15:45 sparc32 git tree Bob Breuer
@ 2006-07-17 17:57 ` Raymond Burns
  2006-07-18  0:42 ` David Miller
                   ` (10 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: Raymond Burns @ 2006-07-17 17:57 UTC (permalink / raw)
  To: sparclinux

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1038 bytes --]

On Mon, 17 Jul 2006, Bob Breuer wrote:

> Ray,
> 
> I think I've found the core problem with the prom properties, and a
> potential problem with the zilog initialization.  Could you try the
> attached patch and let me know if it works for you?
> 
> Thanks,
> Bob

Your patch caused kobject_add to succeed on all duplicate prom items
during the initial tree traversal (55 duplicate or dependent items).

Thank You  :)

I am not able to check the serial port portion yet, mine blows up on
the sbus initialization.

Since it's probably related I have attached the ksymoops output

sbus0 suceeds along with it's 3 dma channels.
prom item:
/io-unit@f,e0200000/sbi@0,0

sbus1 dies
prom item:
/io-unit@f,e1200000/sbi@0,0

(this is sun4d so "sbi" == sbus)
kobject_add failed for sbi@0,0 with -EEXIST, don't try to register
things with the same name in the same directory.

This is followed by the oops which I believe provides more accurate
address info then the trace following the message.

It's probably a sun4d thing, I'll dig.

Thanx
  Ray


[-- Attachment #2: sbus init oops --]
[-- Type: TEXT/PLAIN, Size: 2722 bytes --]

ksymoops 2.4.1 on sparc 2.4.32.  Options used
     -v /sparc.d2/sparc-2.6/arch/sparc/boot/image (specified)
     -K (specified)
     -L (specified)
     -O (specified)
     -M (specified)

Reading Oops report from the terminal
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = ffffffff
tsk->{mm,active_mm}->pgd = fc000000
swapper(1): Oops [#1]
PSR: 408000c1 PC: f00bc8ec NPC: f00bc8f0 Y: 03800000    Not tainted
Using defaults from ksymoops -t elf32-sparc -a sparc
PC: <create_dir+0xc/0x21c>
Caller[f00bcb58]: sysfs_create_dir+0x38/0xa0
Caller[f01041f0]: create_dir+0x24/0x60
Caller[f0104438]: kobject_add+0x5c/0x14c
Caller[f013588c]: device_add+0x84/0x2f8
Caller[f0020688]: of_device_register+0x28/0x80
Caller[f0258b48]: sunzilog_register_serio+0x30/0xc8
Caller[f0259028]: topology_remove_dev+0x4/0x1c
Caller[f0259110]: sparc_lance_probe_one+0x34/0x4e0
Caller[f0242224]: _etext+0x63490/0x64264
Caller[f0014104]: init+0x60/0x19c
Caller[f00195bc]: kernel_thread+0x3c/0x50
Caller[f001401c]: rest_init+0x18/0x34
Caller[f02421b4]: _etext+0x63420/0x64264
Caller[f02417c8]: _etext+0x62a34/0x64264
Caller[00000000]: 0x8
Instruction DUMP: 81c3e008  90102000  9de3bf98 <d006600c> a0100018  40048659  90022074  40014624  9010001a

>>PC;  f00bc8ec <create_dir+4/21c>   <=====
Trace; f00bcb58 <sysfs_create_dir+30/a0>
Trace; f01041f0 <create_dir+1c/60>
Trace; f0104438 <kobject_add+54/14c>
Trace; f013588c <device_add+7c/2f8>
Trace; f0020688 <of_device_register+20/80>
Trace; f0258b48 <fill_sbus_device+114/140>
Trace; f0259028 <build_one_sbus+1a8/204>
Trace; f0259110 <sbus_init+8c/d0>
Trace; f0242224 <do_initcalls+48/168>
Trace; f0014104 <init+58/19c>
Trace; f00195bc <kernel_thread+34/50>
Trace; f001401c <rest_init+10/34>
Trace; f02421b4 <start_kernel+230/244>
Trace; f02417c8 <sun4c_continue_boot+324/334>
Trace; 00000000 Before first symbol
Code;  f00bc8e0 <init_symlink+c/14>
00000000 <_PC>:
Code;  f00bc8e0 <init_symlink+c/14>
   0:   81 c3 e0 08       retl 
Code;  f00bc8e4 <init_symlink+10/14>
   4:   90 10 20 00       clr  %o0
Code;  f00bc8e8 <create_dir+0/21c>
   8:   9d e3 bf 98       save  %sp, -104, %sp
Code;  f00bc8ec <create_dir+4/21c>   <=====
   c:   d0 06 60 0c       ld  [ %i1 + 0xc ], %o0   <=====
Code;  f00bc8f0 <create_dir+8/21c>
  10:   a0 10 00 18       mov  %i0, %l0
Code;  f00bc8f4 <create_dir+c/21c>
  14:   40 04 86 59       call  121978 <_PC+0x121978>
Code;  f00bc8f8 <create_dir+10/21c>
  18:   90 02 20 74       add  %o0, 0x74, %o0
Code;  f00bc8fc <create_dir+14/21c>
  1c:   40 01 46 24       call  518ac <_PC+0x518ac>
Code;  f00bc900 <create_dir+18/21c>
  20:   90 10 00 1a       mov  %i2, %o0


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: sparc32 git tree
  2006-07-17 15:45 sparc32 git tree Bob Breuer
  2006-07-17 17:57 ` Raymond Burns
@ 2006-07-18  0:42 ` David Miller
  2006-07-18  2:07 ` Bob Breuer
                   ` (9 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: David Miller @ 2006-07-18  0:42 UTC (permalink / raw)
  To: sparclinux

From: Bob Breuer <breuerr@mc.net>
Date: Mon, 17 Jul 2006 10:45:16 -0500

> I think I've found the core problem with the prom properties, and a
> potential problem with the zilog initialization.  Could you try the
> attached patch and let me know if it works for you?

The property fix looks good, applied.  Thanks Bob.

The sunzilog change, hmmm... :)

This code works on my SBUS sparc64 machines using zilog serial,
so I wonder what's going wrong.

The sunzilog_alloc_tables() sets up the global list
sunzilog_irq_chain.

All the zilogs hang off of a single interrupt, and therefore
we need that interrupt to process all zilogs in the system.
That's why we pass sunzilog_irq_chain to request_irq().

I double checked the prtconf for a typical SS20 machine,
and both zilog devices have an identical IRQ specification.

This is identical to the behavior of the driver before I made
any changes, for example in 2.6.17.

What could be happening is that the interrupt hits before the
start of the UART struct and device are fully setup.  Perhaps
more of the uart_sunzilog_port initialization should be moved
into sunzilog_alloc_tables(), but there are critical things
we cannot initialize there because we don't have the of_device
object handy yet.

Ok, I think I see what's happening.  We register sunzilog_interrupt
before things like up->port.membase are fully setup.  We init
the first port, by calling sunzilog_init_hw() and that makes
the chip interrupt, I guess.  If that happens, the interrupt
handler will try to read the channel registers of the other
port as well, the pointer to which is still NULL.

Bob, can you confirm this is what is happening by putting some
NULL checks in sunzilog_interrupt or similar?

Thanks.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: sparc32 git tree
  2006-07-17 15:45 sparc32 git tree Bob Breuer
  2006-07-17 17:57 ` Raymond Burns
  2006-07-18  0:42 ` David Miller
@ 2006-07-18  2:07 ` Bob Breuer
  2006-07-18  3:51 ` David Miller
                   ` (8 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: Bob Breuer @ 2006-07-18  2:07 UTC (permalink / raw)
  To: sparclinux

David Miller wrote:
> The sunzilog change, hmmm... :)
> 
> This code works on my SBUS sparc64 machines using zilog serial,
> so I wonder what's going wrong.
> 
> The sunzilog_alloc_tables() sets up the global list
> sunzilog_irq_chain.
> 
> All the zilogs hang off of a single interrupt, and therefore
> we need that interrupt to process all zilogs in the system.
> That's why we pass sunzilog_irq_chain to request_irq().
> 
> I double checked the prtconf for a typical SS20 machine,
> and both zilog devices have an identical IRQ specification.
> 
> This is identical to the behavior of the driver before I made
> any changes, for example in 2.6.17.
> 
> What could be happening is that the interrupt hits before the
> start of the UART struct and device are fully setup.  Perhaps
> more of the uart_sunzilog_port initialization should be moved
> into sunzilog_alloc_tables(), but there are critical things
> we cannot initialize there because we don't have the of_device
> object handy yet.
> 
> Ok, I think I see what's happening.  We register sunzilog_interrupt
> before things like up->port.membase are fully setup.  We init
> the first port, by calling sunzilog_init_hw() and that makes
> the chip interrupt, I guess.  If that happens, the interrupt
> handler will try to read the channel registers of the other
> port as well, the pointer to which is still NULL.
> 
> Bob, can you confirm this is what is happening by putting some
> NULL checks in sunzilog_interrupt or similar?

I was debugging with a serial console, so maybe that caused it to fail
easier.  It triggered an interrupt before initializing the 2nd chip and
ZILOG_CHANNEL_FROM_PORT() was getting a NULL pointer in the interrupt
routine when it looped to the 2nd chip.

Bob


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: sparc32 git tree
  2006-07-17 15:45 sparc32 git tree Bob Breuer
                   ` (2 preceding siblings ...)
  2006-07-18  2:07 ` Bob Breuer
@ 2006-07-18  3:51 ` David Miller
  2006-07-18  4:04 ` David Miller
                   ` (7 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: David Miller @ 2006-07-18  3:51 UTC (permalink / raw)
  To: sparclinux

From: Bob Breuer <breuerr@mc.net>
Date: Mon, 17 Jul 2006 21:07:17 -0500

> I was debugging with a serial console, so maybe that caused it to fail
> easier.  It triggered an interrupt before initializing the 2nd chip and
> ZILOG_CHANNEL_FROM_PORT() was getting a NULL pointer in the interrupt
> routine when it looped to the 2nd chip.

That makes sense.  Ok, let's try the following.  What this
patch does is defer the IRQ registration until after all
the device structures have been setup fully.

It works here on my sparc64 sbus machine.

Let me know how it goes.

diff --git a/drivers/serial/sunzilog.c b/drivers/serial/sunzilog.c
index a1456d9..496810c 100644
--- a/drivers/serial/sunzilog.c
+++ b/drivers/serial/sunzilog.c
@@ -1336,12 +1336,11 @@ static int __devinit zs_get_instance(str
 
 static int zilog_irq = -1;
 
-static int __devinit zs_probe(struct of_device *dev, const struct of_device_id *match)
+static int __devinit zs_probe(struct of_device *op, const struct of_device_id *match)
 {
-	struct of_device *op = to_of_device(&dev->dev);
 	struct uart_sunzilog_port *up;
 	struct zilog_layout __iomem *rp;
-	int inst = zs_get_instance(dev->node);
+	int inst = zs_get_instance(op->node);
 	int err;
 
 	sunzilog_chip_regs[inst] = of_ioremap(&op->resource[0], 0,
@@ -1413,7 +1412,7 @@ static int __devinit zs_probe(struct of_
 		}
 	}
 
-	dev_set_drvdata(&dev->dev, &up[0]);
+	dev_set_drvdata(&op->dev, &up[0]);
 
 	return 0;
 }
@@ -1462,18 +1461,19 @@ static struct of_platform_driver zs_driv
 static int __init sunzilog_init(void)
 {
 	struct device_node *dp;
-	int err;
+	int err, uart_count;
 
 	NUM_SUNZILOG = 0;
 	for_each_node_by_name(dp, "zs")
 		NUM_SUNZILOG++;
 
+	uart_count = 0;
 	if (NUM_SUNZILOG) {
 		int uart_count;
 
 		err = sunzilog_alloc_tables();
 		if (err)
-			return err;
+			goto out;
 
 		/* Subtract 1 for keyboard, 1 for mouse.  */
 		uart_count = (NUM_SUNZILOG * 2) - 2;
@@ -1481,17 +1481,41 @@ static int __init sunzilog_init(void)
 		sunzilog_reg.nr = uart_count;
 		sunzilog_reg.minor = sunserial_current_minor;
 		err = uart_register_driver(&sunzilog_reg);
-		if (err) {
-			sunzilog_free_tables();
-			return err;
-		}
+		if (err)
+			goto out_free_tables;
+
 		sunzilog_reg.tty_driver->name_base = sunzilog_reg.minor - 64;
 		sunzilog_reg.cons = SUNZILOG_CONSOLE();
 
 		sunserial_current_minor += uart_count;
 	}
 
-	return of_register_driver(&zs_driver, &of_bus_type);
+	err = of_register_driver(&zs_driver, &of_bus_type);
+	if (err)
+		goto out_unregister_uart;
+
+	if (zilog_irq != -1) {
+		err = request_irq(zilog_irq, sunzilog_interrupt, IRQF_SHARED,
+				  "zs", sunzilog_irq_chain);
+		if (err)
+			goto out_unregister_driver;
+	}
+
+out:
+	return err;
+
+out_unregister_driver:
+	of_unregister_driver(&zs_driver);
+
+out_unregister_uart:
+	if (NUM_SUNZILOG) {
+		uart_unregister_driver(&sunzilog_reg);
+		sunzilog_reg.cons = NULL;
+	}
+
+out_free_tables:
+	sunzilog_free_tables();
+	goto out;
 }
 
 static void __exit sunzilog_exit(void)

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: sparc32 git tree
  2006-07-17 15:45 sparc32 git tree Bob Breuer
                   ` (3 preceding siblings ...)
  2006-07-18  3:51 ` David Miller
@ 2006-07-18  4:04 ` David Miller
  2006-07-18  4:33 ` Raymond Burns
                   ` (6 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: David Miller @ 2006-07-18  4:04 UTC (permalink / raw)
  To: sparclinux

From: Raymond Burns <rayburns@comcast.net>
Date: Mon, 17 Jul 2006 11:27:50 -0700 (PDT)

> Since it's probably related I have attached the ksymoops output
> 
> sbus0 suceeds along with it's 3 dma channels.
> prom item:
> /io-unit@f,e0200000/sbi@0,0
> 
> sbus1 dies
> prom item:
> /io-unit@f,e1200000/sbi@0,0

It's trying to register a node named "sbi@0,0" at the top-level
of the SBUS hierarchy twice, which thus fails.

These things live in their own namespace, so let's just do the
following to get them named uniquely:

diff --git a/drivers/sbus/sbus.c b/drivers/sbus/sbus.c
index 16b5977..935952e 100644
--- a/drivers/sbus/sbus.c
+++ b/drivers/sbus/sbus.c
@@ -233,7 +233,7 @@ static void __init build_one_sbus(struct
 	sbus->ofdev.node = dp;
 	sbus->ofdev.dev.parent = NULL;
 	sbus->ofdev.dev.bus = &sbus_bus_type;
-	strcpy(sbus->ofdev.dev.bus_id, dp->path_component_name);
+	sprintf(sbus->ofdev.dev.bus_id, "sbus%d", num_sbus);
 
 	if (of_device_register(&sbus->ofdev) != 0)
 		printk(KERN_DEBUG "sbus: device registration error for %s!\n",

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: sparc32 git tree
  2006-07-17 15:45 sparc32 git tree Bob Breuer
                   ` (4 preceding siblings ...)
  2006-07-18  4:04 ` David Miller
@ 2006-07-18  4:33 ` Raymond Burns
  2006-07-18  4:53 ` David Miller
                   ` (5 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: Raymond Burns @ 2006-07-18  4:33 UTC (permalink / raw)
  To: sparclinux

On Mon, 17 Jul 2006, David Miller wrote:

> It's trying to register a node named "sbi@0,0" at the top-level
> of the SBUS hierarchy twice, which thus fails.
> 
> These things live in their own namespace, so let's just do the
> following to get them named uniquely:
> 

exactly what I was trying except wrapped in ifdef CONFIG_SPARC and
if (sparc_cpu_model = sun4d)

I was afraid it would be considered a hack.

Yours works fine by me.

with the sbus happy I've been following the serial port saga, 
(the <#4> looks scary)

zs@1,200000: ttyS0 at MMIO 0x200000 (irq = 12) is a zs
Console: ttyS0 (SunZilog zs0)
zs@1,200000: ttyS1 at MMIO 0x200004 (irq = 12) is a zs
Program terminated
Type  help  for more information
<#4> ok

the result persists despite patches including the last delayed
initialization you sent. sorry.

I need to reinable the early printk to see if there is actually an
oops in there.

Thanx
  Ray



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: sparc32 git tree
  2006-07-17 15:45 sparc32 git tree Bob Breuer
                   ` (5 preceding siblings ...)
  2006-07-18  4:33 ` Raymond Burns
@ 2006-07-18  4:53 ` David Miller
  2006-07-18 19:49 ` Raymond Burns
                   ` (4 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: David Miller @ 2006-07-18  4:53 UTC (permalink / raw)
  To: sparclinux

From: Raymond Burns <rayburns@comcast.net>
Date: Mon, 17 Jul 2006 22:03:17 -0700 (PDT)

> with the sbus happy I've been following the serial port saga, 
> (the <#4> looks scary)
> 
> zs@1,200000: ttyS0 at MMIO 0x200000 (irq = 12) is a zs
> Console: ttyS0 (SunZilog zs0)
> zs@1,200000: ttyS1 at MMIO 0x200004 (irq = 12) is a zs
> Program terminated
> Type  help  for more information
> <#4> ok
> 
> the result persists despite patches including the last delayed
> initialization you sent. sorry.

It's dumping into the firmware on cpu #4.

Why don't you try a non-SMP kernel while we work out these
device level problems?  This crash here might be related
to the erroneous SLAB patch you put in there.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: sparc32 git tree
  2006-07-17 15:45 sparc32 git tree Bob Breuer
                   ` (6 preceding siblings ...)
  2006-07-18  4:53 ` David Miller
@ 2006-07-18 19:49 ` Raymond Burns
  2006-07-18 19:50 ` Raymond Burns
                   ` (3 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: Raymond Burns @ 2006-07-18 19:49 UTC (permalink / raw)
  To: sparclinux

On Mon, 17 Jul 2006, David Miller wrote:

> It's dumping into the firmware on cpu #4.
> 
> Why don't you try a non-SMP kernel while we work out these
> device level problems?  This crash here might be related
> to the erroneous SLAB patch you put in there.

compiled as non-SMP, the recovering cpu is #0, the logged result
persists.

ctrace showed an interesting thought, I anotated with the System map
values.

udelay is the only place I see getting to .umul and not sure what it's
choking on ( 5 isn't that exotic ).

no I haven't been playing in lib/umul.S

Thanx
  Ray



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: sparc32 git tree
  2006-07-17 15:45 sparc32 git tree Bob Breuer
                   ` (7 preceding siblings ...)
  2006-07-18 19:49 ` Raymond Burns
@ 2006-07-18 19:50 ` Raymond Burns
  2006-07-19 16:36 ` Raymond Burns
                   ` (2 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: Raymond Burns @ 2006-07-18 19:50 UTC (permalink / raw)
  To: sparclinux

[-- Attachment #1: Type: TEXT/PLAIN, Size: 67 bytes --]


It would help if I added the attached ..... 

sorry

Thanx
  Ray


[-- Attachment #2: ctrace --]
[-- Type: TEXT/PLAIN, Size: 965 bytes --]


f0030954 T printk
call f0030954    from f001c42c
     e w  %o0-%o5: ( f01d3080 fd03e000 f01f9774 f01cb810        1 f0cbc460 )

f001c3ac t unhandled_fault
call f001c3ac    from f001c924
     f w  %o0-%o5: ( fd03e000 f0cc8b80 f0cd1980   280700       60 f00fbfa0 )

f001c558 T do_sparc_fault
call f001c558    from f0011138
    10 w  %o0-%o5: ( f0cd1980        0 fc000000 fd03e000        0 f0e7505a )

f00fdac8 T .umul
call f00fdac8    from f001174c
    11 w  %o0-%o5: ( ffffffff        0        0 f0cd1e20 f00fc9a0      13b )

f0121200 t read_zsreg
call f0121200    from f0121c10
    12 w  %o0-%o5: ( fd03e004        3 ec000000 f01cb810        4 f025a400 )

f0121bec t sunzilog_interrupt
jmpl  f0121bec    from f0013cf8
    13 w  %o0-%o5: ( fd03e004 f0cd6000 f0cd1b68 f0121bec        0 f0cbb808 )

f0013c70 T sun4d_handler_irq
call f0013c70    from f00109d0
    14 w  %o0-%o5: (        c f0cd1b68        0 f0cd62dc fe5fffff     1000 )



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: sparc32 git tree
  2006-07-17 15:45 sparc32 git tree Bob Breuer
                   ` (8 preceding siblings ...)
  2006-07-18 19:50 ` Raymond Burns
@ 2006-07-19 16:36 ` Raymond Burns
  2006-07-20  5:45 ` David Miller
  2006-07-21  3:50 ` Raymond Burns
  11 siblings, 0 replies; 13+ messages in thread
From: Raymond Burns @ 2006-07-19 16:36 UTC (permalink / raw)
  To: sparclinux

Hi

zs_get_instance returns a value 0 or 1 . zs occurance greater then
that never get structure initialized.

What I did was set up->port.membase to null in sunzilog_alloc_tables
then a for loop to pick next available in zs_get_instance.

A simple init space global counter would work as well

The next stumble originated in sunzilog_init, accounting for mouse and
keyboard left the uart_count 2 short of the number of serial ports.


my tree's a mess


Thanx
  Ray




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: sparc32 git tree
  2006-07-17 15:45 sparc32 git tree Bob Breuer
                   ` (9 preceding siblings ...)
  2006-07-19 16:36 ` Raymond Burns
@ 2006-07-20  5:45 ` David Miller
  2006-07-21  3:50 ` Raymond Burns
  11 siblings, 0 replies; 13+ messages in thread
From: David Miller @ 2006-07-20  5:45 UTC (permalink / raw)
  To: sparclinux

From: Raymond Burns <rayburns@comcast.net>
Date: Wed, 19 Jul 2006 09:36:27 -0700 (PDT)

> zs_get_instance returns a value 0 or 1 . zs occurance greater then
> that never get structure initialized.

So stupid, sorry about that.   This logic will definitely not
work for sun4d, especially ss2000 systems.

Let's do the instance enumeration like the following patch.
It should do the right thing and it shouldn't mark some of
your sun4d zilogs as being for the keyboard/mouse :)

diff --git a/drivers/serial/sunzilog.c b/drivers/serial/sunzilog.c
index 18df10f..0f68fbd 100644
--- a/drivers/serial/sunzilog.c
+++ b/drivers/serial/sunzilog.c
@@ -68,9 +68,6 @@ static int num_sunzilog;
 #define NUM_SUNZILOG	num_sunzilog
 #define NUM_CHANNELS	(NUM_SUNZILOG * 2)
 
-#define KEYBOARD_LINE 0x2
-#define MOUSE_LINE    0x3
-
 #define ZS_CLOCK		4915200 /* Zilog input clock rate. */
 #define ZS_CLOCK_DIVISOR	16      /* Divisor this driver uses. */
 
@@ -1225,12 +1222,10 @@ static void __init sunzilog_init_kbdms(s
 {
 	int baud, brg;
 
-	if (channel = KEYBOARD_LINE) {
-		up->flags |= SUNZILOG_FLAG_CONS_KEYB;
+	if (up->flags & SUNZILOG_FLAG_CONS_KEYB) {
 		up->cflag = B1200 | CS8 | CLOCAL | CREAD;
 		baud = 1200;
 	} else {
-		up->flags |= SUNZILOG_FLAG_CONS_MOUSE;
 		up->cflag = B4800 | CS8 | CLOCAL | CREAD;
 		baud = 4800;
 	}
@@ -1243,14 +1238,14 @@ static void __init sunzilog_init_kbdms(s
 }
 
 #ifdef CONFIG_SERIO
-static void __init sunzilog_register_serio(struct uart_sunzilog_port *up, int channel)
+static void __init sunzilog_register_serio(struct uart_sunzilog_port *up)
 {
 	struct serio *serio = &up->serio;
 
 	serio->port_data = up;
 
 	serio->id.type = SERIO_RS232;
-	if (channel = KEYBOARD_LINE) {
+	if (up->flags & SUNZILOG_FLAG_CONS_KEYB) {
 		serio->id.proto = SERIO_SUNKBD;
 		strlcpy(serio->name, "zskbd", sizeof(serio->name));
 	} else {
@@ -1259,7 +1254,8 @@ static void __init sunzilog_register_ser
 		strlcpy(serio->name, "zsms", sizeof(serio->name));
 	}
 	strlcpy(serio->phys,
-		(channel = KEYBOARD_LINE ? "zs/serio0" : "zs/serio1"),
+		((up->flags & SUNZILOG_FLAG_CONS_KEYB) ?
+		 "zs/serio0" : "zs/serio1"),
 		sizeof(serio->phys));
 
 	serio->write = sunzilog_serio_write;
@@ -1286,8 +1282,8 @@ static void __init sunzilog_init_hw(stru
 		(void) read_zsreg(channel, R0);
 	}
 
-	if (up->port.line = KEYBOARD_LINE ||
-	    up->port.line = MOUSE_LINE) {
+	if (up->flags & (SUNZILOG_FLAG_CONS_KEYB |
+			 SUNZILOG_FLAG_CONS_MOUSE)) {
 		sunzilog_init_kbdms(up, up->port.line);
 		up->curregs[R9] |= (NV | MIE);
 		write_zsreg(channel, R9, up->curregs[R9]);
@@ -1313,36 +1309,26 @@ static void __init sunzilog_init_hw(stru
 	spin_unlock_irqrestore(&up->port.lock, flags);
 
 #ifdef CONFIG_SERIO
-	if (up->port.line = KEYBOARD_LINE || up->port.line = MOUSE_LINE)
-		sunzilog_register_serio(up, up->port.line);
+	if (up->flags & (SUNZILOG_FLAG_CONS_KEYB |
+			 SUNZILOG_FLAG_CONS_MOUSE))
+		sunzilog_register_serio(up);
 #endif
 }
 
-static int __devinit zs_get_instance(struct device_node *dp)
-{
-	int ret;
-
-	ret = of_getintprop_default(dp, "slave", -1);
-	if (ret != -1)
-		return ret;
-
-	if (of_find_property(dp, "keyboard", NULL))
-		ret = 1;
-	else
-		ret = 0;
-
-	return ret;
-}
-
 static int zilog_irq = -1;
 
 static int __devinit zs_probe(struct of_device *op, const struct of_device_id *match)
 {
+	static int inst;
 	struct uart_sunzilog_port *up;
 	struct zilog_layout __iomem *rp;
-	int inst = zs_get_instance(op->node);
+	int keyboard_mouse;
 	int err;
 
+	keyboard_mouse = 0;
+	if (of_find_property(op->node, "keyboard", NULL))
+		keyboard_mouse = 1;
+
 	sunzilog_chip_regs[inst] = of_ioremap(&op->resource[0], 0,
 					      sizeof(struct zilog_layout),
 					      "zs");
@@ -1369,7 +1355,7 @@ static int __devinit zs_probe(struct of_
 	up[0].port.line = (inst * 2) + 0;
 	up[0].port.dev = &op->dev;
 	up[0].flags |= SUNZILOG_FLAG_IS_CHANNEL_A;
-	if (inst = 1)
+	if (keyboard_mouse)
 		up[0].flags |= SUNZILOG_FLAG_CONS_KEYB;
 	sunzilog_init_hw(&up[0]);
 
@@ -1386,11 +1372,11 @@ static int __devinit zs_probe(struct of_
 	up[1].port.line = (inst * 2) + 1;
 	up[1].port.dev = &op->dev;
 	up[1].flags |= 0;
-	if (inst = 1)
+	if (keyboard_mouse)
 		up[1].flags |= SUNZILOG_FLAG_CONS_MOUSE;
 	sunzilog_init_hw(&up[1]);
 
-	if (inst != 1) {
+	if (!keyboard_mouse) {
 		err = uart_add_one_port(&sunzilog_reg, &up[0].port);
 		if (err) {
 			of_iounmap(rp, sizeof(struct zilog_layout));
@@ -1406,6 +1392,8 @@ static int __devinit zs_probe(struct of_
 
 	dev_set_drvdata(&op->dev, &up[0]);
 
+	inst++;
+
 	return 0;
 }
 
@@ -1454,10 +1442,15 @@ static int __init sunzilog_init(void)
 {
 	struct device_node *dp;
 	int err, uart_count;
+	int num_keybms;
 
 	NUM_SUNZILOG = 0;
-	for_each_node_by_name(dp, "zs")
+	num_keybms = 0;
+	for_each_node_by_name(dp, "zs") {
 		NUM_SUNZILOG++;
+		if (of_find_property(dp, "keyboard", NULL))
+			num_keybms++;
+	}
 
 	uart_count = 0;
 	if (NUM_SUNZILOG) {
@@ -1467,8 +1460,7 @@ static int __init sunzilog_init(void)
 		if (err)
 			goto out;
 
-		/* Subtract 1 for keyboard, 1 for mouse.  */
-		uart_count = (NUM_SUNZILOG * 2) - 2;
+		uart_count = (NUM_SUNZILOG * 2) - (2 * num_keybms);
 
 		sunzilog_reg.nr = uart_count;
 		sunzilog_reg.minor = sunserial_current_minor;

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: sparc32 git tree
  2006-07-17 15:45 sparc32 git tree Bob Breuer
                   ` (10 preceding siblings ...)
  2006-07-20  5:45 ` David Miller
@ 2006-07-21  3:50 ` Raymond Burns
  11 siblings, 0 replies; 13+ messages in thread
From: Raymond Burns @ 2006-07-21  3:50 UTC (permalink / raw)
  To: sparclinux

On Wed, 19 Jul 2006, David Miller wrote:

> Let's do the instance enumeration like the following patch.
> It should do the right thing and it shouldn't mark some of
> your sun4d zilogs as being for the keyboard/mouse :)

This is on target, lets see that the other subarchitectures are
working. 

Attempts to remove request_irq() from zs_probe have failed and I still
have a NULL check in the interrupt service routine.

Currently it does initialize the zs subsystem, I need to see some
details available in user land before I can claim no tuning needed.


Working this from a serial console has it's challanges.

Thanx
  Ray



^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2006-07-21  3:50 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-17 15:45 sparc32 git tree Bob Breuer
2006-07-17 17:57 ` Raymond Burns
2006-07-18  0:42 ` David Miller
2006-07-18  2:07 ` Bob Breuer
2006-07-18  3:51 ` David Miller
2006-07-18  4:04 ` David Miller
2006-07-18  4:33 ` Raymond Burns
2006-07-18  4:53 ` David Miller
2006-07-18 19:49 ` Raymond Burns
2006-07-18 19:50 ` Raymond Burns
2006-07-19 16:36 ` Raymond Burns
2006-07-20  5:45 ` David Miller
2006-07-21  3:50 ` Raymond Burns

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.