On Sun, 29 Dec 2002 20:46:05 -0500 (MET), Veit Kannegieser wrote:
>>I know, but normal DEVICE-PDDs should receive the notification at the same time (on
>Ring-0
>tasktime), so
>>INITCOMPLETE is the only chance. Otherwise I would need to send it out several times
>(and of
>course for
>>different drivers).
>But allowing it before initcomplete allows a driver
>to print some simple diagnostic/error messages.
We are talking about Hot-Plugging, not normal devices. So it's more probably that the
supported device(s) are
not even plugged in during bootup. Point-enabled devices are something different, but
those are listed in the
non Hot-Plug group, so they exist for not-hot-plugable drivers. Diagnostic messages
may get printed out via
COM-port like done, when using USB drivers.
If a user wants to use a hot-plug devices using a non-hotplug-capable driver, he (or
the daemon) has to select
it. The socket will then get ignored by hotplug services (GCONFIG speaking) and the
actual device will get
listed in the normal PCI-group as well. This means that OEMHLP$ will find it (and
allow access to it).
Otherwise such devices won't get found nor will they be accessible via (OEMHLP$) PCI
Read/Write-Configuration space APIs.
>>There is some sort of configuration space or something in PCMCIA. Isn't that one
>>listing the resource requirements?
>There are Tuple data, but you can not be sure if it
>trustworthy for all devices, and if full configuration is
>needed, it will most likely depend on card use/driver.
Hmm. I think I will definitely add a sub-block for this "tuple" data, so the driver(s)
won't need to ask for it
manually. Anyway: How should it made possible to configure such device on-the-fly, if
the "tuple" data is
wrong? I mean if some more memory needs to get mapped into cardbus controller, then I
won't even know
how much memory is needed. That's definitely impractical.
If the "tuple" data specifies e.g. 256 bytes of memory and 16 I/O Range, then I can
put that into a resource
proposal block. Even if there are multiple configurations possible (like on PnP), then
this is possible, because
there may be multiple proposal blocks as well.
Well, I don't even have a clue how this "tuple" data is built up, so it would be great
if someone could send me
some documentation.
>>There would be a possibility. It would be clean and imho good. GCONFIG sees any
>attach/detachment
>of
>>devices and looks for a matching configuration area entry. If one matches, then it
>will use the
>configuration
>>specified there. Using that scheme, it would be possible.
>>The downside would be that multiple devices would allocate space even if they are
>not attached.
>autodrv2.sys does it this way: PM configuration program burns data tables
>into driver file.
I don't know what you mean by "burn"? You mean it modifies the drivers binary or
sending some
"device-configuration-block" to the driver?
Also I need to know how much memory, I/O and IRQ(s) a given device needs. Then I can
fit the resource
window(s) to fit. Everything else would need driver interaction and that's definitely
unpractical (especially for
point-enabled drivers). How are they supposed to work? I mean they need a configured
device. I can't
enlarge a resource window on-the-fly, because I would have to leave room for it. Also
I wouldn't even know
how much resources a given device needs and this whole configuration needs to be
synched somehow.
cu, Kiewitz
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
