On 03-Oct-2002 Mitsuru IWASAKI wrote:
>> ># I could be wrong, please correct me :)
>> >I think that Libretto 110CT doesn't have PCI-ISA bridge , so no isab,
>> >no isa, no isahint (requires isa) w/ acpi enabled.
>>
>> Hmmm, \_SB.PCI0.EIO has no _ADR, _HID instead.
>> But I think ISA or LPC controller exists in this system.
>
> Adding some device ID to isa_pci.c will solve this?
> OK, I enclose dmesg w/ boot -v from mark's first post for convenience.
> ----
> pci0: physical bus=0
> found-> vendor=0x1179, dev=0x0601, revid=0x2e
> bus=0, slot=0, func=0
> class=06-00-00, hdrtype=0x00, mfdev=0
> map[10]: type 3, range 32, base fd000000, size 24, enabled
> map[14]: type 1, range 32, base ffc00000, size 21, enabled
> map[18]: type 1, range 32, base ffb00000, size 20, enabled
> found-> vendor=0x10c8, dev=0x0004, revid=0x01
> bus=0, slot=4, func=0
> class=03-00-00, hdrtype=0x00, mfdev=0
> intpin=a, irq=255
> map[10]: type 4, range 32, base 00000000, size 5, port disabled
> found-> vendor=0x1179, dev=0x0701, revid=0x22
> bus=0, slot=17, func=0
> class=07-80-00, hdrtype=0x00, mfdev=0
> intpin=a, irq=255
> found-> vendor=0x1179, dev=0x060f, revid=0x20
> bus=0, slot=19, func=0
> class=06-07-00, hdrtype=0x02, mfdev=1
> intpin=a, irq=255
> found-> vendor=0x1179, dev=0x060f, revid=0x20
> bus=0, slot=19, func=1
> class=06-07-00, hdrtype=0x02, mfdev=1
> intpin=b, irq=255
> ----
PCI-ISA bridges are class 06-01-00, which none of those are so that
wouldn't work.
>> >In legacy case, we have at least isa0 on motherboard even if there
>> >is no ISA bridge. OTOH, we never see isa0 if there is no ISA bridge
>> >in ACPI case.
>> >Also, most of isa device driver (more than 70!) don't have acpi
>> >attachment yet, including some important drivers such as sc0.
Well, IMO, they really should be attaching to isa0, not acpi0.
>> >Hmmm, it's not so simple...
>> >How about having acpi_isa bus code so that we have at least isa0
>> >on the system w/o ISA bridge ?
>>
>> Is that be able multiple multipule isa bus exist in the system?
>
> I'm not sure, but my thought was something like following patches.
>
> Thanks
>
> Index: dev/acpica/acpi.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v
> retrieving revision 1.75
> diff -u -r1.75 acpi.c
> --- dev/acpica/acpi.c 6 Sep 2002 17:01:06 -0000 1.75
> +++ dev/acpica/acpi.c 3 Oct 2002 10:13:51 -0000
> @@ -777,6 +777,10 @@
> if (ACPI_SUCCESS(AcpiGetHandle(ACPI_ROOT_OBJECT, scopes[i], &parent)))
> AcpiWalkNamespace(ACPI_TYPE_ANY, parent, 100, acpi_probe_child, bus, NULL);
>
> + if (devclass_get_device(devclass_find("isa"), 0) == NULL) {
> + device_set_flags(BUS_ADD_CHILD(bus, 0, "isa", 0), 1);
> + }
> +
> /*
> * Scan all of the child devices we have created and let them probe/attach.
> */
Might want to check return value of BUS_ADD_CHILD().
> Index: isa/isa_common.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/isa/isa_common.c,v
> retrieving revision 1.31
> diff -u -r1.31 isa_common.c
> --- isa/isa_common.c 30 Sep 2002 07:56:12 -0000 1.31
> +++ isa/isa_common.c 3 Oct 2002 10:13:04 -0000
> @@ -1107,6 +1107,60 @@
> 1, /* no softc */
> };
>
> +static int
> +acpi_isa_probe(device_t dev)
> +{
> +
> + if (device_get_flags(dev) == 0) {
> + return (ENXIO);
> + }
> +
> + return (isa_probe(dev));
> +}
> +
> +static device_method_t acpi_isa_methods[] = {
> + /* Device interface */
> + DEVMETHOD(device_probe, acpi_isa_probe),
> + DEVMETHOD(device_attach, isa_attach),
> + DEVMETHOD(device_detach, bus_generic_detach),
> + DEVMETHOD(device_shutdown, bus_generic_shutdown),
> + DEVMETHOD(device_suspend, bus_generic_suspend),
> + DEVMETHOD(device_resume, bus_generic_resume),
> +
> + /* Bus interface */
> + DEVMETHOD(bus_add_child, isa_add_child),
> + DEVMETHOD(bus_print_child, isa_print_child),
> + DEVMETHOD(bus_probe_nomatch, isa_probe_nomatch),
> + DEVMETHOD(bus_read_ivar, isa_read_ivar),
> + DEVMETHOD(bus_write_ivar, isa_write_ivar),
> + DEVMETHOD(bus_child_detached, isa_child_detached),
> + DEVMETHOD(bus_driver_added, isa_driver_added),
> + DEVMETHOD(bus_setup_intr, isa_setup_intr),
> + DEVMETHOD(bus_teardown_intr, isa_teardown_intr),
> +
> + DEVMETHOD(bus_get_resource_list,isa_get_resource_list),
> + DEVMETHOD(bus_alloc_resource, isa_alloc_resource),
> + DEVMETHOD(bus_release_resource, isa_release_resource),
> + DEVMETHOD(bus_set_resource, isa_set_resource),
> + DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
> + DEVMETHOD(bus_delete_resource, bus_generic_rl_delete_resource),
> + DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
> + DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
> +
> + /* ISA interface */
> + DEVMETHOD(isa_add_config, isa_add_config),
> + DEVMETHOD(isa_set_config_callback, isa_set_config_callback),
> + DEVMETHOD(isa_pnp_probe, isa_pnp_probe),
> +
> + { 0, 0 }
> +};
> +
> +static driver_t acpi_isa_driver = {
> + "isa",
> + acpi_isa_methods,
> + 1, /* no softc */
> +};
> +
> /*
> * ISA can be attached to a PCI-ISA bridge or directly to the legacy device.
> */
> @@ -1114,4 +1168,5 @@
> DRIVER_MODULE(isa, eisab, isa_driver, isa_devclass, 0, 0);
> #ifdef __i386__
> DRIVER_MODULE(isa, legacy, isa_driver, isa_devclass, 0, 0);
> +DRIVER_MODULE(isa, acpi, acpi_isa_driver, isa_devclass, 0, 0);
> #endif
Hmm, this is ok for now I guess. If the actual driver is going to
be MI, I think the DRIVER_MODULE() should be MI. I don't like
abusing a device flag like that though. Hmmm. I think it would
be better if instead we attached an isab driver to the actual device
that we find in the namespace and then let it add an isa child. I
guess this can go in for now. I'll think some more about this. It
is possible to have an ACPI machine w/o an ISA bus and we shouldn't
be adding ISA busses to all ACPI machines.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
