lkml.org 
[lkml]   [2005]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: serial8250_init and platform_device
    Date
    Russell,

    I think this all makes sense to me. I'm just wondering why we would
    have a platform device register in a system for 'legacy ISA' when we
    know the system doesnt have any ports that will fit the category.

    As you show in example #2 you have

    .../devices/platform/serial82500
    .../devices/platform/serial8250

    why have the 'serial8250' if you know your system doesnt have any ports
    that will exist there?

    - kumar

    On Jan 20, 2005, at 9:44 AM, Russell King wrote:

    > On Thu, Jan 20, 2005 at 09:23:56AM -0600, Kumar Gala wrote:
    > > No problem, let me try to clarify.  I'm trying to figure out in the
    > ARM
    > > case if there are 2 platform_devices that are registered and if
    > this is
    > > the desired behavior (and if so why?).
    >
    > Yes.  The first (by serial8250_init) is the ISA compatibility platform
    > device, which registers the "old" static list of serial devices found
    > in include/asm-*/serial.h.
    >
    > The second registers a platform device which contains the 8250 serial
    > devices for the particular platform.
    >
    > > In serial8250_init() we call platform_device_register_simple(), this
    > > will be one registration of a serial8250 device.  In my example of
    > > vr1000, arch/arm/mach-s3c2410/cpu.c:s3c_arch_init() calls
    > > platform_device_register, the 2nd time a serial8250 device is
    > > registered.
    >
    > Correct.
    >
    > > > We then register the device driver, which allows us to pick up on
    > the
    > > >  platform devices.  This causes the placeholder registrations to
    > be
    > > >  reassigned to the platform devices on a first come first served
    > basis
    > > >  via the standard registration call serial8250_register_port().
    > >
    > > I'm not following you here, its not clear if you mean we have 2
    > > platform devices registered in the system, but only one actually has
    > > serial ports that are registered.
    >
    > We have two platform devices registered - one representing the
    > compatibility devices, and one (or more) representing the platform's
    > own devices.
    >
    > To illustrate this, let's assume your architecture always has ports at
    > a fixed set of addresses, and then has a set of platform specific
    > ports.
    > You may wish to have one platform device for the platform common
    > serial
    > devices which always gets registered.  Your platform specific
    > initialisation code could then register another platform device which
    > contains details of the platform specific serial devices.
    >
    > > If you are using SERIAL_PORT_DFNS,
    > > it will be the platform_device created in serial8250_init(), if you
    > are
    > > not it will be the platform_device created elsewhere?
    >
    > Initially, all serial devices are attached to the platform device
    > created in serial8250_init(), whether or not they are listed in
    > SERIAL_PORT_DFNS or not.  Serial devices not listed in
    > SERIAL_PORT_DFNS
    > remain in an unconfigured state.
    >
    > When the 8250 platform device driver is registered, serial devices
    > are "stolen" from this "private" platform device, and are owned by
    > the platform device which registered them.
    >
    > Lets take some examples:
    >
    > 1. SERIAL_PORT_DFNS contains port at 0x3f8, irq4, and we have space for
    >    4 serial ports.  No other platform devices are registered.
    >
    > # cat /proc/tty/driver/serial
    > serinfo:1.0 driver revision:
    > 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
    > 1: uart:unknown port:00000000 irq:0
    > 2: uart:unknown port:00000000 irq:0
    > 3: uart:unknown port:00000000 irq:0
    > # tree /sys/class/tty/ttyS*
    > /sys/class/tty/ttyS0
    > |-- dev
    > `-- device -> ../../../devices/platform/serial8250
    > /sys/class/tty/ttyS1
    > |-- dev
    > `-- device -> ../../../devices/platform/serial8250
    > /sys/class/tty/ttyS2
    > |-- dev
    > `-- device -> ../../../devices/platform/serial8250
    > /sys/class/tty/ttyS3
    > |-- dev
    > `-- device -> ../../../devices/platform/serial8250
    >
    > 2. SERIAL_PORT_DFNS contains port at 0x3f8, irq4, and we have space for
    >    4 serial ports.  A platform device also describing 0x3f8, irq 4 is
    >    registered.
    >
    > # cat /proc/tty/driver/serial
    > serinfo:1.0 driver revision:
    > 0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
    > 1: uart:unknown port:00000000 irq:0
    > 2: uart:unknown port:00000000 irq:0
    > 3: uart:unknown port:00000000 irq:0
    > # tree /sys/class/tty/ttyS*
    > /sys/class/tty/ttyS0
    > |-- dev
    > |-- device -> ../../../devices/platform/serial82500
    > `-- driver -> ../../../bus/platform/drivers/serial8250
    > /sys/class/tty/ttyS1
    > |-- dev
    > `-- device -> ../../../devices/platform/serial8250
    > /sys/class/tty/ttyS2
    > |-- dev
    > `-- device -> ../../../devices/platform/serial8250
    > /sys/class/tty/ttyS3
    > |-- dev
    > `-- device -> ../../../devices/platform/serial8250
    >
    > 3. SERIAL_PORT_DFNS is empty, otherwise the same as case (2).  Results
    >    are identical to case (2).
    >
    > HTH.
    >
    > --
    > Russell King
    >  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
    >  maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
    >                  2.6 Serial core

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:0.029 / U:58.416 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site