Hello.
Ashlesha Shintre wrote:
3) control goes into the serial8250_probe function and assigns values
from the plat_serial8250_port encm3_via_uart_data to the port..so what
is the basic difference between registration of "probe device" versus
"platform bus" devices in the 2.6 kernel?
I'm not sure I follow you here.
What I meant was, what was the basis for the implementation of
platform_device and platform_init functions in 2.6?
This is a convenient way to registers the various SoC and on-board devices
residing on the busses that can't be scanned like ISA/LPC/whatever (and unlike
PCI, for example).
By my understanding the way it worked in 2.4 was by the device probing
functions that would allocate memory, io ports etc..
Basically, you don't need to probe for device which you *know* is there,
you just need to tell the driver where it is.
m working on making the changes you suggested --
without the addition of the platform_device and other structures, the
I meant that you *only* need struct plat_serial8250_port, and not
platform_device.
serial console is never detected -- I never get a msg at boot time that
reads
serial8250: ttyS0 at I/O 0x3f8 (irq = whatever) is a 16550A
so I think i might need these routines
Also, the Southbridge interrupts are assigned interrupt number:
AU1000_GPIO_0..and I have included this as below:
Ah, I forgot to mention that if your UART is a part of the south bridge,
its IRQ number is _4_ on the integrated 8259 interrupt controller. I'm sure
that AU1000_GPIO_0 is the cascaded interrupt request from 8259, not the UART's
own IRQ...
static struct plat_serial8250_port encm3_via_uart_data[] = {
{
.mapbase = 0x3f8,
.irq = AU1000_GPIO_0,
So, this is wrong. You need to specify to what platform IRQ 8259's IRQ4
gets routed here.
Thanks again!
Ashlesha.
WBR, Sergei
