On Mon, 30 Dec 2002 16:31:29 +0100 (CET), Jimi wrote:
>>But allowing it before initcomplete allows a driver
>>to print some simple diagnostic/error messages.
True.
>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.
This assumption just doesn't hold in reality. I know that from my own
experiences and user reports running DaniS506 with CompactFlash cards.
It's more convenient to many users to have PCCard/Cardbus cards
inserted all time.
>>>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.
The latter point is a strong one! Consider CompactFlash cards: these
typically may be configured in two basic modes, a memory mapped one and
an IO mapped one. It depends on the driver, which mode it supports.
Usually there are multiple possible IO mapping configurations offered
by the cards, some on fixed well-known port locations, and typically
one which accepts any suitable address range. The driver than has to
enumerate all possible configurations with its requirements until it
finds one which matches the driver's needs and doesn't clash with any
other resources already assigned anywhere in the system (taking into
account the 10-bit decoding issues).
>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.
I've never seen a PCCard device with bad configuration info, but many
which lack other less vital information tuples.
>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.
To provide this info you'll have to parse the configuration tuples in a
generic way. The best solution would be to offer a completely filled
ConfigurationInfo structure with proposed non-clashing resource
allocations. Anything less makes no sense because it would require
*full* handling of the tuple parsing/resource management/configuration
stuff in the driver just like today.
>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.
The PCMCIA specs are not available for free, but most of the stuff can
be found anywhere. Or have a look into the CS.C source I sent some days
ago.
>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?
Yes.
Ciao,
Dani
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
