Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Nov 2004 14:44:10 +0000 (UTC)
From:      Marius Strobl <marius@FreeBSD.org>
To:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/dev/uart uart_cpu_sparc64.csrc/sys/modules/uart Makefile src/sys/sparc64/isa isa.c
Message-ID:  <200411171444.iAHEiAkm070318@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
marius      2004-11-17 14:44:10 UTC

  FreeBSD src repository

  Modified files:
    sys/dev/uart         uart_cpu_sparc64.c 
    sys/modules/uart     Makefile 
    sys/sparc64/isa      isa.c 
  Log:
  o sparc64/isa/isa.c:
    - The claim in the commit log of rev. 1.11 of dev/uart/uart_cpu_sparc64.c
      etc. that UARTs are the only relevant ISA devices on sparc64 turned out
      to be false. While there are sparc64 models where UARTs are the only
      devices on the ISA bus there are in fact also low-cost models where all
      devices traditionally found on the EBus are hooked up to the ISA bus.
      There are also models that use a mix between EBus and ISA devices with
      things like an AT keyboard controller and other rather interesting
      devices that we might want to support in the futute hook up to the ISA
      bus.
      In order to not need to add sparc64 specific device_identify methods to
      all of the respective ISA drivers and also not add OFW specific code to
      the common ISA code make the sparc64 ISA bus code fake up PnP devices so
      most ISA drivers probe their devices without further changes.
      Unfortunately Sun doesn't adhere to the ISA bindings defined in IEEE
      1275-1994 for the properties of most of the ISA devices which would
      allow to obtain the vendor and logical IDs from their properties. So we
      we just use a simple table which maps the name properties to PnP IDs.
      This could be done in a more sophisticated way but I courrently don't
      see the need for this. [1]
    - Add the children with fully mapped and specified resources (in the OFW
      sense) similar to what is done in the EBus code for the IRQ resources
      of the children as adjusting the resources and the resource list entries
      respectively in isa_alloc_resource() as done perviously causes trouble
      with drivers which use rman_get_start(), pass-through or allocate and
      release resources multiple times, etc.
      Adjusting the resources might be better off in a bus_activate_resource
      method but the common ISA code currently doesn't allow for an
      isa_activate_resource(). [2]
      With this change:
      - ppbus(4) and lpt(4) attach and work (modulo ECP mode, which requires
        real ISADMA code but it currently only consists of stubs on sparc64).
      - atkbdc(4) and atkbdc(4) attach, no further testing done.
      - fdc(4) itself attaches but causes a hang while attaching fd0 also
        when is DMA disabled, further work in fdc(4) is required here as e.g.
        fd0 uses the address of fd1 on sparc64 (not sure if sparc64 supports
        more than one floppy drive at all).
      All of these drivers previously caused panics in the sparc64 ISA code.
    - Minor changes, e.g. use __FBSDID, remove a dupe word in a comment and
      declare one global variable which isn't used outside of isa.c static.
  o dev/uart/uart_cpu_sparc64.c and modules/uart/Makefile:
    - Remove the code for registering the UARTs on the ISA bus from the
      sparc64 uart_cpu_identify() again and rely on probing them via PnP.
  
  Original idea by:       tmm [1]
  No objections by:       tmm [1], [2]
  
  Revision  Changes    Path
  1.13      +1 -41     src/sys/dev/uart/uart_cpu_sparc64.c
  1.12      +2 -7      src/sys/modules/uart/Makefile
  1.14      +186 -112  src/sys/sparc64/isa/isa.c



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411171444.iAHEiAkm070318>