[patch 2.6.13-git] 8250 tweaks

[patch 2.6.13-git] 8250 tweaks

[David Brownell]

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

Two small changes:  make the IRQ name less generic, and stop
whining about certain non-errors (details in the patch comments).
Please merge.

- Dave


[-- Attachment #2: 8250.patch --]
[-- Type: text/x-diff, Size: 1159 bytes --]

Make the 8250 UART driver register its IRQ using a label that's more
appropriate ... it's an 8250 UART, not one of dozens of other kind of
serial link (I2C, SPI, USB, McBSP, I2S, non-8250 UART, USART, SSP,
MicroWire, PS/2 kbd/mouse/touchpad, MCSI, HDQ/1-Wire, ... etc).

Also, make it stop whining when one of the platform serial ports has
been disabled, e.g. because a given board doesn't wire it out.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

--- o26.orig/drivers/serial/8250.c	2005-07-11 18:41:03.000000000 -0700
+++ o26/drivers/serial/8250.c	2005-07-11 18:58:26.000000000 -0700
@@ -1317,7 +1317,7 @@ static int serial_link_irq_chain(struct 
 		spin_unlock_irq(&i->lock);
 
 		ret = request_irq(up->port.irq, serial8250_interrupt,
-				  irq_flags, "serial", i);
+				  irq_flags, "uart_8250", i);
 		if (ret < 0)
 			serial_do_unlink(i, up);
 	}
@@ -2331,6 +2331,8 @@ static int __devinit serial8250_probe(st
 	memset(&port, 0, sizeof(struct uart_port));
 
 	for (i = 0; p && p->flags != 0; p++, i++) {
+		if (!p->iobase && !p->membase)
+			continue;
 		port.iobase	= p->iobase;
 		port.membase	= p->membase;
 		port.irq	= p->irq;

Re: [patch 2.6.13-git] 8250 tweaks

[Russell King]

On Mon, Jul 11, 2005 at 07:22:04PM -0700, David Brownell wrote:
> and stop
> whining about certain non-errors (details in the patch comments).

Please explain what the whining is (details were missing from the
patch comments).

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 2.6.13-git] 8250 tweaks

[Russell King]

On Tue, Jul 12, 2005 at 08:19:43AM +0100, Russell King wrote:
> On Mon, Jul 11, 2005 at 07:22:04PM -0700, David Brownell wrote:
> > and stop
> > whining about certain non-errors (details in the patch comments).
> 
> Please explain what the whining is (details were missing from the
> patch comments).

Exasperated sigh.

Just in case someone thinks I'm being bloody stupid and didn't read the
patch (as discovered via a private mail), I'd like the _whining_ expanded
upon (eg, what is the message) and not the reasons why.

I though it would have been obvious but it seems that it isn't...

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 2.6.13-git] 8250 tweaks

[david-b]

> Date: Tue, 12 Jul 2005 08:19:43 +0100
> From: Russell King <rmk+lkml@arm.linux.org.uk>
>
> On Mon, Jul 11, 2005 at 07:22:04PM -0700, David Brownell wrote:
> > and stop
> > whining about certain non-errors (details in the patch comments).
>
> Please explain what the whining is (details were missing from the
> patch comments).

The kernel "recently" started issuing the second and third messages
after initializing the serial port on for example an OSK board:

    ttyS0 at MMIO 0xfffb0000 (irq = 46) is a ST16654
    serial8250 serial8250.0: unable to register port at index 1 (IO0 MEM0 IRQ47): -28
    serial8250 serial8250.0: unable to register port at index 2 (IO0 MEM0 IRQ15): -28

Of the three serial ports potentially available on that board, by default
only the UART1 is available, and the others are marked as unavailable
by zeroing the register pointers in that platform_data.  That makes it
easy to support setups where for example UART1/ttyS0 and UART3/ttyS2 are
wired, and the pins for ttyS1 are muxed to some other purpose like USB
or MMC, or similarly boards where only UART2 is wired up.

- Dave

Re: [patch 2.6.13-git] 8250 tweaks

[Russell King]

On Tue, Jul 12, 2005 at 03:25:12AM -0700, david-b@pacbell.net wrote:
> > Date: Tue, 12 Jul 2005 08:19:43 +0100
> > From: Russell King <rmk+lkml@arm.linux.org.uk>
> >
> > On Mon, Jul 11, 2005 at 07:22:04PM -0700, David Brownell wrote:
> > > and stop
> > > whining about certain non-errors (details in the patch comments).
> >
> > Please explain what the whining is (details were missing from the
> > patch comments).
> 
> The kernel "recently" started issuing the second and third messages
> after initializing the serial port on for example an OSK board:
> 
>     ttyS0 at MMIO 0xfffb0000 (irq = 46) is a ST16654
>     serial8250 serial8250.0: unable to register port at index 1 (IO0 MEM0 IRQ47): -28
>     serial8250 serial8250.0: unable to register port at index 2 (IO0 MEM0 IRQ15): -28

Thanks, that's exactly what I wanted to know.

-28 is -ENOSPC which means that you've run out of available serial devices
to register these others.

If you wish to have three ports in an plat_serial8250_port array, you'll
need to ensure that CONFIG_SERIAL_8250_NR_UARTS is set to at least 3.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 2.6.13-git] 8250 tweaks

[david-b]

> >     ttyS0 at MMIO 0xfffb0000 (irq = 46) is a ST16654
> >     serial8250 serial8250.0: unable to register port at index 1 (IO0 MEM0 IRQ47): -28
> >     serial8250 serial8250.0: unable to register port at index 2 (IO0 MEM0 IRQ15): -28
>
> Thanks, that's exactly what I wanted to know.
>
> -28 is -ENOSPC which means that you've run out of available serial devices
> to register these others.

The idea is _not_ to register them on boards that only have a
single RS232 connector.  The fix was just having the 8250 code
understand that it should only register ports that are real.


> If you wish to have three ports in an plat_serial8250_port array, you'll
> need to ensure that CONFIG_SERIAL_8250_NR_UARTS is set to at least 3.

That is, there's no third way which (a) doesn't waste that memory,
and (b) doesn't produce annoying messages about non-error cases?

ISTR that having NR_UARTS bigger just produced different messages...

- Dave

Re: [patch 2.6.13-git] 8250 tweaks

[Russell King]

On Tue, Jul 12, 2005 at 04:32:12AM -0700, david-b@pacbell.net wrote:
> > >     ttyS0 at MMIO 0xfffb0000 (irq = 46) is a ST16654
> > >     serial8250 serial8250.0: unable to register port at index 1 (IO0 MEM0 IRQ47): -28
> > >     serial8250 serial8250.0: unable to register port at index 2 (IO0 MEM0 IRQ15): -28
> >
> > Thanks, that's exactly what I wanted to know.
> >
> > -28 is -ENOSPC which means that you've run out of available serial devices
> > to register these others.
> 
> The idea is _not_ to register them on boards that only have a
> single RS232 connector.  The fix was just having the 8250 code
> understand that it should only register ports that are real.

The tty code doesn't work like that.  You must know how many ports
you want right from the start.  You can't dynamically add new ports
to an already registered driver without first unregistering all the
existing ports, unregistering the driver, adjusting the number of
ports, reregistering the driver and all the ports.

If you've got one already open, your only option in that case is to
ignore any attempt to add new ports.

Obviously this is not acceptable.  So please don't try to dictate
what serial should do.  It does things the way it does them to work
around other bits of the kernel which are lacking in various ways.

> > If you wish to have three ports in an plat_serial8250_port array, you'll
> > need to ensure that CONFIG_SERIAL_8250_NR_UARTS is set to at least 3.
> 
> That is, there's no third way which (a) doesn't waste that memory,
> and (b) doesn't produce annoying messages about non-error cases?

Correct.

> ISTR that having NR_UARTS bigger just produced different messages...

Which were?

It works for me on my platforms here, and everyone else on x86.  I
even had a situation where I had NR_UARTS set to 64 but only one
registered... which also worked fine with no extraneous kernel
messages.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 2.6.13-git] 8250 tweaks

[david-b]

> > The idea is _not_ to register them on boards that only have a
> > single RS232 connector.  The fix was just having the 8250 code
> > understand that it should only register ports that are real.
>
> The tty code doesn't work like that.  You must know how many ports
> you want right from the start.

That ** IS ** the start ... the messages came out as the 8250
driver was registering and binding to the platform device.


>	You can't dynamically add new ports
> to an already registered driver without first unregistering all the
> existing ports, unregistering the driver, adjusting the number of
> ports, reregistering the driver and all the ports.

... so I have no idea why you think there's any dynamic addition
of new ports, or that the driver was already registered, or that
the number of ports is being changed, or any of that.


> If you've got one already open, your only option in that case is to
> ignore any attempt to add new ports.
>
> Obviously this is not acceptable.

Good thing none of that is being tried, then!!


>	So please don't try to dictate
> what serial should do.

In no way am _I_ trying to "dictate" anything.


>	It does things the way it does them to work
> around other bits of the kernel which are lacking in various ways.

I understand working around, of course.  But I fail to see how
emitting error messages for non-error cases does anyone any good.


> > > If you wish to have three ports in an plat_serial8250_port array, you'll
> > > need to ensure that CONFIG_SERIAL_8250_NR_UARTS is set to at least 3.
> > 
> > That is, there's no third way which (a) doesn't waste that memory,
> > and (b) doesn't produce annoying messages about non-error cases?
>
> Correct.

That doesn't seem necessary, given the simple "don't try to register
ports unless they're enabled" patch you saw.  Or desirable.


> > ISTR that having NR_UARTS bigger just produced different messages...
>
> Which were?

Error code 22 instead of 28, as I recall.  And as I said, the
appearance of any (bogus error) message is a "recent" change.
Two months ago, there were no messages at all.


> It works for me on my platforms here, and everyone else on x86.  I
> even had a situation where I had NR_UARTS set to 64 but only one
> registered... which also worked fine with no extraneous kernel
> messages.

But it was certainly wasting the memory for 63 ports.

- Dave

Re: [patch 2.6.13-git] 8250 tweaks

[Russell King]

On Tue, Jul 12, 2005 at 06:30:43AM -0700, david-b@pacbell.net wrote:
> > > ISTR that having NR_UARTS bigger just produced different messages...
> >
> > Which were?
> 
> Error code 22 instead of 28, as I recall.  And as I said, the
> appearance of any (bogus error) message is a "recent" change.
> Two months ago, there were no messages at all.

We now have multiple 8250 platform devices.  I'm sure folk would
want to know if one of their serial ports fails to register.  Hence
the message.  It's not bogus!

22 is EINVAL, which will occur if uartclk is zero, or if the port was
trying to be registered was already registered (not possible.)

So, you're asking the driver to register a port with zero MMIO, IO and
clock values...  Ok, you're asking the driver to do something that is
invalid.  Sounds like its the platform code which is doing the bogus
things.

I don't see why you can't just pass those that you want and no more.
Either build the table dynamically with just the ports that you want
listed and the rest completely zeroed, or register several platform
devices, one for each port.

You don't need any special hacks in the 8250 driver to "support" this.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 2.6.13-git] 8250 tweaks

[Sam Song]

Russell King <rmk+lkml@arm.linux.org.uk> wrote:
[snip]
> It works for me on my platforms here, and everyone
> else on x86. I even had a situation where I had
> NR_UARTS set to 64 but only one registered... which 
> also worked fine with no extraneous kernel messages.

But seems not functional on PowerPC platform. I used
a MPC8241 which has a DURT inside to try the git tree
8250.c and got the following result:

u-boot=> run kt
Please enter 'kernel-test':uImage-26-13
TFTP from server 192.168.57.200; our IP address is
192.168.57.243
Filename 'uImage-26-13'.
Load address: 0x1200000
Loading: ###########################################
        
####################################################
done
Bytes transferred = 858760 (d1a88 hex)
## Booting image at 01200000 ...
   Image Name:   Linux-2.6.13-rc1
   Image Type:   PowerPC Linux Kernel Image (gzip
compressed)
   Data Size:    858696 Bytes = 838.6 kB
   Load Address: 00000000
   Entry Point:  00000000
   Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at ff950000 ...
   Image Name:   Ramdisk ttyS1
   Image Type:   PowerPC Linux RAMDisk Image (gzip
compressed)
   Data Size:    1478758 Bytes =  1.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Loading Ramdisk to 03dde000, end 03f47066 ... OK
Linux version 2.6.13-rc1 (root@sam.shu.org) (gcc
version 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-5
......
Built 1 zonelists
Kernel command line: console=ttyS1,115200
root=/dev/ram0 rw ramdisk_size=200000
ip=192.168.57.243:192.168.57.200:::8241:eth1
OpenPIC Version 1.2 (1 CPUs and 7 IRQ sources) at 
fdf40000
OpenPIC timer frequency is 100.000000 MHz
PID hash table entries: 512 (order: 9, 8192 bytes)
time_init: decrementer frequency = 25.000000 MHz
Dentry cache hash table entries: 16384 (order: 4,
65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768
bytes)
Memory: 61268k available (1548k kernel code, 388k
data, 104k init, 0k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (no cpio
magic); looks like an initrd
Freeing initrd memory: 1444k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 1 of device
0000:00:00.0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 
bytes)
Installing knfsd (copyright (C) 1996 
okir@monad.swb.de).
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports,
IRQ sharing disabled
ttyS0 at MMIO 0x0 (irq = 5) is a 16550A
ttyS1 at MMIO 0x0 (irq = 6) is a 16550A
serial8250 serial8250.0: unable to register port at
index 0 (IO0 MEMfdf04500 IRQ25): -22
serial8250 serial8250.0: unable to register port at
index 1 (IO0 MEMfdf04600 IRQ26): -22
io scheduler noop registered
RAMDISK driver initialized: 16 RAM disks of 200000K
size 1024 blocksize
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
......
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Device `eth0' not found.
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 104k init
serial console detected.  Disabling virtual terminals.
### Application running ...

BusyBox v0.60.1 (2002.10.24-04:52+0000) Built-in 
shell (msh)
Enter 'help' for a list of built-in commands.

# cat /proc/interrupts
           CPU0
  6:         39   OpenPIC   Level     serial
BAD:          3

The whining is a little bit different from david's.
ttyS1 conosle was a workable one but ttyS1 didn't 
register right??? After applied David's patch, it 
became normal as before like 2.6.12-rc2 did. 

So my puzzle comes to know why ttyS1 cannot register
right even it works well.

TTA,

Sam

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [patch 2.6.13-git] 8250 tweaks

[Russell King]

On Tue, Jul 12, 2005 at 09:55:22PM -0700, Sam Song wrote:
> But seems not functional on PowerPC platform. I used
> a MPC8241 which has a DURT inside to try the git tree
> 8250.c and got the following result:

I don't know what's going on here - I don't know the PPC code
internals at all, or what you're running.

However, if you merely lifted the later 8250.c and put it into a
previous kernel (which looks like the case), there's other changes
in addition which are required.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 2.6.13-git] 8250 tweaks

[Sam Song]

Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> However, if you merely lifted the later 8250.c and
> put it into a previous kernel (which looks like the 
> case), there's other changes in addition which are 
> required.

Good catch. I tried 2.6.13-rc1 and the newest version
2.6.13-rc3 on the same target[MPC8241]. The whining 
remained the same. 

Thanks,

Sam


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250

Re: [patch 2.6.13-git] 8250 tweaks

[Russell King]

On Wed, Jul 13, 2005 at 03:51:26AM -0700, Sam Song wrote:
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > However, if you merely lifted the later 8250.c and
> > put it into a previous kernel (which looks like the 
> > case), there's other changes in addition which are 
> > required.
> 
> Good catch. I tried 2.6.13-rc1 and the newest version
> 2.6.13-rc3 on the same target[MPC8241]. The whining 
> remained the same. 

v. whining

    1. To utter a plaintive, high-pitched, protracted sound, as in pain,
       fear, supplication, or complaint.
    2. To complain or protest in a childish fashion.
    3. To produce a sustained noise of relatively high pitch: jet engines
       whining.

The kernel isn't doing any of those.

Anyway, you're going to have to help me out a lot - I don't know a
thing about PPC, so I don't know what a MPC8241 is.  I don't know
your kernel configuration (could you send it please?) so I don't
know which files are trying to be built.

Also, having the contents of /sys/devices/platform or
/sys/bus/platform/* would be useful.

For some reason, it appears that the serial driver is being asked to
register two serial ports at MMIO address 0, from one platform device,
which it apparantly detects as being present.  I suspect these are
coming from some table included via asm-ppc/serial.h, but where that
is I've no idea.

It's then asked to add two more ports from the serial8250.0 device,
which doesn't exist.  These come from a platform device in arch/ppc.
Again, where these come from I don't know.

So.  The serial driver is being asked to create _four_ ports.  It's
created two, but can't create the other two, failing with error -22.
22 is EINVAL, which means there was something wrong with what was
requested.  That generally points to uartclk being zero, which would
be a bug in the PPC architecture code.  You can confirm this by
applying this patch:

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2333,6 +2333,7 @@ static int __devinit serial8250_probe(st
 			dev_err(dev, "unable to register port at index %d "
 				"(IO%lx MEM%lx IRQ%d): %d\n", i,
 				p->iobase, p->mapbase, p->irq, ret);
+			printk(KERN_ERR "uartclk was %d\n", port.uartclk);
 		}
 	}
 	return 0;

(For those cogito fanatics, the above simple patch took 1min 22sec for
cg-diff to spit out!)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 2.6.13-git] 8250 tweaks

[Sam Song]

Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> v. whining
> 
>     1. To utter a plaintive, high-pitched,
> protracted sound, as in pain,
>        fear, supplication, or complaint.
>     2. To complain or protest in a childish fashion.
>     3. To produce a sustained noise of relatively
> high pitch: jet engines
>        whining.
> 
> The kernel isn't doing any of those.

Oops, I misused this word. Thanks for your correction.
 
> Anyway, you're going to have to help me out a lot -

I'd love to:-)

> Also, having the contents of /sys/devices/platform
> or /sys/bus/platform/* would be useful.
> 
> For some reason, it appears that the serial driver
> is being asked to register two serial ports at MMIO 
> address 0, from one platform device,
> which it apparantly detects as being present.  I
> suspect these are coming from some table included 
> via asm-ppc/serial.h, but where that
> is I've no idea.
> 
> It's then asked to add two more ports from the
> serial8250.0 device, which doesn't exist.  These 
> come from a platform device in arch/ppc.
> Again, where these come from I don't know.

It doesn't matter. Your notes is good enough to put
me the right direction to find out the bug in my 
platform.

> So.  The serial driver is being asked to create
> _four_ ports.  It's created two, but can't create 
> the other two, failing with error -22.
> 22 is EINVAL, which means there was something wrong
> with what was requested.  That generally points to 
> uartclk being zero, which would
> be a bug in the PPC architecture code.  You can
> confirm this by applying this patch:

Sure. The uartclk printed zero. Your simple patch
did a good help. Then I tracked down to the _four_
port registering and finally picked out the "bug".

It turned out the conflict of uart init definition 
like MPC10X_UART0_IRQ in ../syslib/mpc10x_common.c 
and SERIAL_PORT_DFNS in ../platform/sandpoint.h. By
now, only MPC10X_UART0_IRQ stuff is needed. 
SERIAL_PORT_DFNS should be omitted. 

Seems it's time for me to stand with Russell:-)

I must confess that I am a stupid guy on kernel 
programming. The result on PPC side, I mean sandpoint
board, still needs Mark's confirmation.

Following is the bug-fixed boot log on a custom
8241 board. 

Loading kernel ......
Linux version 2.6.13-rc3 (root@sam.acs.net) (gcc
version 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-
......
Based on the Freescale Sandpoint Development System
Built 1 zonelists
Kernel command line: console=ttyS1,115200 
root=/dev/nfs rw
nfsroot=192.168.57.200:/opt/eldk3/ppc_82xx 
ip=192.168.57.243:192.1OpenPIC
Version 1.2 (1 CPUs and 11 IRQ sources) at fdf40000
OpenPIC timer frequency is 100.000000 MHz
PID hash table entries: 512 (order: 9, 8192 bytes)
time_init: decrementer frequency = 25.000000 MHz
Dentry cache hash table entries: 16384 (order: 4, 
65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 
bytes)
Memory: 62848k available (1572k kernel code, 388k 
data, 104k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 1 of device 
0000:00:00.0
inotify syscall
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096
bytes)
Installing knfsd (copyright (C) 1996
okir@monad.swb.de).
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports,
IRQ sharing disabled
ttyS0 at MMIO 0xfdf04500 (irq = 9) is a 16550A
ttyS1 at MMIO 0xfdf04600 (irq = 10) is a 16550A
io scheduler noop registered
RAMDISK driver initialized: 16 RAM disks of 4096K size
1024 blocksize
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
......
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
      device=eth0, addr=192.168.57.243,
mask=255.255.255.0,
gw=255.255.255.255,
     host=8241, domain=, nis-domain=(none),
     bootserver=192.168.57.200,
rootserver=192.168.57.200, rootpath=
Looking up port of RPC 100003/2 on 192.168.57.200
Looking up port of RPC 100005/1 on 192.168.57.200
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 104k init
INIT: version 2.84 booting
        Welcome to DENX Embedded Linux Environment
        Press 'I' to enter interactive startup.
Building the cache [  OK  ]
Mounting proc filesystem:  [  OK  ]
Configuring kernel parameters:  [  OK  ]
......
Mounting NFS filesystems:  [  OK  ]
Mounting other filesystems:  [  OK  ]
Starting xinetd: [  OK  ]

8241 login: root
Last login: Wed Dec 31 19:00:33 on console
bash-2.05b# ls
bash-2.05b# cd /
bash-2.05b# ls
bin   dev  images  lib    mnt   root  tmp  var
boot  etc  proc  sbin  usr
bash-2.05b# cat /proc/interrupts
           CPU0
  0:      18707   OpenPIC   Level     eth0
 10:        258   OpenPIC   Level     serial
BAD:         14

Thanks for your time,

Sam

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [patch 2.6.13-git] 8250 tweaks

[Russell King]

On Thu, Jul 14, 2005 at 12:12:02AM -0700, Sam Song wrote:
> It turned out the conflict of uart init definition 
> like MPC10X_UART0_IRQ in ../syslib/mpc10x_common.c 
> and SERIAL_PORT_DFNS in ../platform/sandpoint.h. By
> now, only MPC10X_UART0_IRQ stuff is needed. 
> SERIAL_PORT_DFNS should be omitted. 

Oh dear, it seems that I missed a load of fixups then.  I only
scanned include/asm-* for SERIAL_PORT_DFNS - and I stupidly
thought that PPC this "platform" directory would be in include/asm-ppc.

> Seems it's time for me to stand with Russell:-)

Well, in this case, the "whinging" resulted in finding a _real_ bug
and locating why your ports weren't being found.  So I guess it's
good for something.

Can you mail me a diff of the changes you made to
arch/ppc/platforms/sandpoint.h please?  If that file is being used
it seems that you actually have 4 ports defined in total.  However,
I'm a little confused because the sandpoint.h defines don't seem to
match your original dmesg output.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 2.6.13-git] 8250 tweaks

[Sam Song]

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

Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> Well, in this case, the "whinging" resulted in
> finding a _real_ bug and locating why your ports 
> weren't being found.  So I guess it's
> good for something.

Indeed! The old kernel didn't have such an advantage.

> Can you mail me a diff of the changes you made to
> arch/ppc/platforms/sandpoint.h please?  

Certainly. 

> If that file is being used it seems that you 
> actually have 4 ports defined in total.  However,
> I'm a little confused because the sandpoint.h
> defines don't seem to match your original dmesg 
> output.

Well, I use a sandpoint-based board. Not the same as
the reference one. There are two serial ports on the
board and I enabled them both with IRQ9/10. 
In addition, No 8259 on this board.

Pls don't apply this patch:-)

Thanks,

Sam


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

[-- Attachment #2: 2389572820-sandpoint-8250.diff --]
[-- Type: application/octet-stream, Size: 3227 bytes --]

diff -urN linux-2.6.13-rc3/arch/ppc/platforms/sandpoint.c linux-2.6.13-rc3-8241/arch/ppc/platforms/sandpoint.c
--- linux-2.6.13-rc3/arch/ppc/platforms/sandpoint.c	2005-07-13 12:46:46.000000000 +0800
+++ linux-2.6.13-rc3-8241/arch/ppc/platforms/sandpoint.c	2005-07-15 12:52:08.000000000 +0800
@@ -320,9 +320,8 @@
 
 			/* this disables the 2nd serial port on the DUART
 			 * since the sandpoint does not have it connected */
-			pdata[1].uartclk = 0;
-			pdata[1].irq = 0;
-			pdata[1].mapbase = 0;
+			pdata[1].uartclk = bp->bi_busfreq;
+			pdata[1].membase = ioremap(pdata[1].mapbase, 0x100);
 		}
 	}
 
diff -urN linux-2.6.13-rc3/arch/ppc/platforms/sandpoint.h linux-2.6.13-rc3-8241/arch/ppc/platforms/sandpoint.h
--- linux-2.6.13-rc3/arch/ppc/platforms/sandpoint.h	2005-07-13 12:46:46.000000000 +0800
+++ linux-2.6.13-rc3-8241/arch/ppc/platforms/sandpoint.h	2005-07-15 12:45:14.000000000 +0800
@@ -51,30 +51,13 @@
 /*
  * Serial defines.
  */
-#define SANDPOINT_SERIAL_0		0xfe0003f8
-#define SANDPOINT_SERIAL_1		0xfe0002f8
-
-#define RS_TABLE_SIZE  2
-
+#define RS_TABLE_SIZE  4
+                                                                                                                             
 /* Rate for the 1.8432 Mhz clock for the onboard serial chip */
-#define BASE_BAUD			( 1843200 / 16 )
-#define UART_CLK			1843200
-
-#ifdef CONFIG_SERIAL_DETECT_IRQ
-#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF|ASYNC_AUTO_IRQ)
-#else
-#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF)
-#endif
-
-#define STD_SERIAL_PORT_DFNS \
-        { 0, BASE_BAUD, SANDPOINT_SERIAL_0, 4, STD_COM_FLAGS, /* ttyS0 */ \
-		iomem_base: (u8 *)SANDPOINT_SERIAL_0,			  \
-		io_type: SERIAL_IO_MEM },				  \
-        { 0, BASE_BAUD, SANDPOINT_SERIAL_1, 3, STD_COM_FLAGS, /* ttyS1 */ \
-		iomem_base: (u8 *)SANDPOINT_SERIAL_1,			  \
-		io_type: SERIAL_IO_MEM },
-
-#define SERIAL_PORT_DFNS \
-        STD_SERIAL_PORT_DFNS
+#define BASE_BAUD                       ( 100000000 / 16 ) /* 100Mhz speed, divided by 16
+                                                            * to make the output freqency */
+#define UART_CLK                        1843200
+                                                                                                                             
+#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF|ASYNC_SKIP_TEST)
 
 #endif /* __PPC_PLATFORMS_SANDPOINT_H */
diff -urN linux-2.6.13-rc3/arch/ppc/syslib/mpc10x_common.c linux-2.6.13-rc3-8241/arch/ppc/syslib/mpc10x_common.c
--- linux-2.6.13-rc3/arch/ppc/syslib/mpc10x_common.c	2005-07-13 12:46:46.000000000 +0800
+++ linux-2.6.13-rc3-8241/arch/ppc/syslib/mpc10x_common.c	2005-07-15 12:50:39.000000000 +0800
@@ -41,10 +41,10 @@
 #else
 #define EPIC_IRQ_BASE 5
 #endif
-#define MPC10X_I2C_IRQ (EPIC_IRQ_BASE + NUM_8259_INTERRUPTS)
-#define MPC10X_DMA0_IRQ (EPIC_IRQ_BASE + 1 + NUM_8259_INTERRUPTS)
-#define MPC10X_DMA1_IRQ (EPIC_IRQ_BASE + 2 + NUM_8259_INTERRUPTS)
-#define MPC10X_UART0_IRQ (EPIC_IRQ_BASE + 4 + NUM_8259_INTERRUPTS)
+#define MPC10X_I2C_IRQ (EPIC_IRQ_BASE)
+#define MPC10X_DMA0_IRQ (EPIC_IRQ_BASE + 1)
+#define MPC10X_DMA1_IRQ (EPIC_IRQ_BASE + 2)
+#define MPC10X_UART0_IRQ (EPIC_IRQ_BASE + 4)
 #else
 #define MPC10X_I2C_IRQ -1
 #define MPC10X_DMA0_IRQ -1

Re: [patch 2.6.13-git] 8250 tweaks

[Russell King]

On Thu, Jul 14, 2005 at 10:11:36PM -0700, Sam Song wrote:
> Well, I use a sandpoint-based board. Not the same as
> the reference one. There are two serial ports on the
> board and I enabled them both with IRQ9/10. 
> In addition, No 8259 on this board.
> 
> Pls don't apply this patch:-)

Indeed I won't.  I was hoping that it was going to be something simple,
but it's not.  We need PPC folk to fix their SERIAL_PORT_DFNS and
remove obsolete stuff like RS_TABLE_SIZE.

Ideally, SERIAL_PORT_DFNS should end up being completely empty.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 2.6.13-git] 8250 tweaks

[Sam Song]

Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> but it's not.  We need PPC folk to fix their
> SERIAL_PORT_DFNS and remove obsolete stuff like 
> RS_TABLE_SIZE.

Hope Mark could take care this change. I have no
sandpoint board at hand:-)

I removed RS_TABLE_SIZE on my target successfully
and happened to found that there was other file like
../syslib/gen550_dbg.c required SERIAL_PORT_DFNS 
as well which could use for KGDB or sth.

> Ideally, SERIAL_PORT_DFNS should end up being
> completely empty.

It has implemented on my target:-)

Still one puzzle related serial port. That's interrupt
itself. I enabled two serial ports attached two 
different interrupt levels like 9/10 with disable 
interrupt shared. How come only one appeared 
in /proc/interrupts? What could be on your platform
or they should be?

Thanks a lot,

Sam

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [patch 2.6.13-git] 8250 tweaks

[Russell King]

On Sat, Jul 16, 2005 at 03:12:01AM -0700, Sam Song wrote:
> Still one puzzle related serial port. That's interrupt itself. I
> enabled two serial ports attached two different interrupt levels
> like 9/10 with disable interrupt shared. How come only one appeared 
> in /proc/interrupts? What could be on your platform or they should be?

The interrupts are only claimed when the port is actually opened, so if
only one port was open, you'll only see one appearing in /proc/interrupts.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [patch 2.6.13-git] 8250 tweaks

[Sam Song]

Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> The interrupts are only claimed when the port is
> actually opened, so if
> only one port was open, you'll only see one
> appearing in /proc/interrupts.

Get it.

Thanks so much,

Sam


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs