On Mon, 30 Dec 2002 18:38:40 +0100 (CET), Daniela Engert 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.
The question is: How to do it?
I mean DaniS506 is loaded during BASEDEVINIT, PCMCIA drivers are loaded at that time
as well. I wanted to
hook myself into those and not the other way round (which would mean writing a driver
that would support
PCMCIA and include itself into GCONFIG). That's also true for USB. For that case, I
will use INITCOMPLETE,
because it's even the first time that USBD actually recognizes any USB devices. For
PCMCIA (of course) it
would be possible to detect it earlier, but how to generate support and also how to
actually generate the
notifications? At INITCOMPLETE, all notification hooks should be done already. If I
generate notification
before, this would require my driver to remember which device already got notified to
which driver and isn't
quite good. I would still prefer to start the notifications at INITCOMPLETE, *but* a
programmer could look for
already attached devices using Find-APIs (from GCONFIG). Also I think the
notifications of those devices
would still occur on the driver. The question remains how to hook. Another solution
would be to generate a
new PCMCIA/Cardbus driver that includes GCONFIG support so actually making that driver
compliant and
generating a public API to generate/destroy HWDevices.
>>>>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).
Well, multiple configurations can (and are already) handled by GCONFIG due generating
multiple resource
proposal sub-blocks for a device. Anyway, I have no clue how to *proper* implement
this extreme case.
Configuration of those devices should be done via configuration area (at least that's
how it's supposed to
work) and not by the driver. Also this configuration would need to get synchronized
*with* the driver which is
somewhat impossible, because of e.g. resource windows.
Let me give you an example:
I have 2 PCMCIA devices. Got a Cardbus controller.
Now the first one gets inserted. It's detected, found by GCONFIG. It finds out that no
configuration is
available, so it says "new device" and "oops, this one needs resources". This will
notify the daemon and that
one should normally prompt the user for driver installation, resource assignment and
so on. Okay, we need a
driver in that case (because we don't know what type of configuration to use). User
selects one, installs,
reboot. Now the device gets found, configuration entry is found but no actual resource
configuration. Nothing
is applied to device nor cardbus controller. Driver is loaded now, says "great, got a
supported device. I wanna
get I/O mapped". So what happens now? It's impossible to adjust the resource window
later especially if
point-enabled drivers are loaded *as well*. Or how should I adjust it in that case??
Another possibility would be: Reserving *any* needed resources just to be on the safe
side.
e.g. device offers 256 I/O ports or memory mapped I/O (2048 bytes). GCONFIG finds
device, user selects
driver. GCONFIG knows how much resources that device may use (in using any
configuration), remembers
that in configuration area. User reboots. GCONFIG recognizes device again. Notices
that it's known. For
configuring cardbus controller, it adds all configurations that exist (!) together and
makes resource windows
using those values.
This way some resources would get wasted, but who cares. At least it would work. The
driver could still
choose whatever he/she ;-) wants and everyone should be fine.
Of course, this would require hotplug-drivers to support GCONFIG in some way or am I
wrong here? I mean
how should a Cardbus hotplug driver know, which resource window got set? Or is this
supported in the
PCMCIA API somehow?
>>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.
This would mean exactly?
And how are PCMCIA devices identified? By VendorID/DeviceID as well or some other type
of identification?
>>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.
Of course, that's what I want to do. I'm already doing this with PnP and PCI devices.
All this information goes
into PROPosal blocks in BASE-Block sub-blocks.
For example my soundblaster awe64gold looks that way:
Found DEVICE-Block
-> BASE-Block
- HWDeviceID 01010100
- Version 2.0
- Class 0.0.0 (Unknown/Undefined)
- DeviceID 0E8C:0044
- Card-DeviceID 0E8C:009E
- CompatDeviceID 0E8C:009E
-> NAME-Block
- Creative SB AWE64 Gold Audio
-> PROP-Block
- IRQ 5
- DMA 1
- DMA 5
- I/O 0220, Length 16
- I/O 0330, Length 2
- I/O 0388, Length 4
-> PROP-Block
- IRQ range 5,7,9,10
- DMA range 0,1,3
- DMA range 5,6,7
- I/O range, Start 0220, End 0280, Align 32, Length 16
- I/O range, Start 0300, End 0330, Align 48, Length 2
- I/O 0388, Length 4
-> PROP-Block
- IRQ range 5,7,9,10
- DMA range 0,1,3
- DMA range 5,6,7
- I/O range, Start 0220, End 0280, Align 32, Length 16
- I/O range, Start 0300, End 0330, Align 48, Length 2
[...]
>>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.
If someone in here has the specs, it would be really great, if that one could send me
those. I would really
appreciate it.
>>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.
I assume that's "Yes it sends some device configuration block to the driver"?
So I assume there is some API called "Select Configuration" as well so the driver is
able to select one of the
possible configuration possibilities?
cu, Kiewitz
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
