On Tue, 31 Dec 2002 19:34:49 +0100 (CET), Daniela Engert wrote:
>>>>How should such resource
>>>>assignment work in that case? Or would I need to assign something from within the
>window and ignore
the
>>>>0x330h request at all?
>>>I don't understand your concerns here. The windows are set up by the
>>>card services & socket services driver at the point of
>>>RequestConfiguration by the client driver.
>>
>>My question is: If a device requests a specific I/O address, I would need to
>generate a window for it on
>>cardbus. But as I am limited with just 2 windows (and for memory this is actually 1
>window, because of
>>prefetchable/non-prefetchable state), I would have problems when having to assign
>e.g. 330h, 360h and
>>870h onto PCMCIA. I can't use a window from 330h->870h.
>Both PCCard and CardBus have only two IO windows and thus
>PCCards/Cardbus cards won't request more than two IO regions at a time.
But there may be multiple PCMCIA devices. So if I got 2 devices and both request 2
specific I/O locations, the
cardbus controller isn't able to fullfill the request.
>>>>Tuple #5, code = 0x1a (Configuration map), length = 5
>>>> 000: 01 06 d0 0f 0b
>>>> Reg len = 2, config register addr = 0xfd0, last config = 0x6
>>>> Registers: XX-X----
>>>>^^^^
>>>>No idea what this is for
>>>You don't have to care about this stuff. Card services do this for you.
>>Yes, but I will need to put as much information into BASE and SUB-block.
>No other driver but card/socket services knows how to access these
>registers at all! They sit in the attribute space.
Well, because I didn't have a clue whats this tuple is about. I couldn't know :-)
>>Also the configuration of the
>>cardbus controller needs to get done by GCONFIG, because the cardbus driver is not
>able to know what
>>devices may get assigned, so it would need to e.g. dynamically reassign the resource
>window (which is
>>impossible due point-enabled drivers).
>The above describes exactly parts of the duties of the socket services
>driver.
>I understand your purpose with GCONFIG less with each sentence you
>write. Is there some document about that? Do you want to replace socket
>services and card services? If so I'd expect nobody will use GCONFIG.
I have already explained it in another mail (at least to some aspect).
It's there to get a generic way for device detection (not dependant on the type of
device). It's there to
configure certain devices (like PnP and PCI), it's there to generate generic hotplug
events, offer a new
easy-to-use-with-plain-C, also simulate old API(s) like OEMHLP$ PCI and have generic
memory structures for
all sorts of devices, so that device searching or identifying only needs to be done
once.
The design is based on 2 areas. One is detection and contains fixed information about
the current devices in
the system. As soon as a new device is found, this device is searched for in the
configuration area (!). This
one gets written by a Ring-3 daemon to a file and is loaded during bootup and then the
found configuration is
applied to the device. If the device is not found, it gets marked as "fresh device".
If it's found, but no
configuration is included and/or a special flag is set, the device won't get touched,
but current configuration
(from e.g. BIOS) will get put into detected area in resource manager. If a
configuration isn't able to get applied,
then the device will get disabled or won't get touched at all (depending on device
type).
In any way, if a device gets matched, this device will get marked in the configuration
area. If another device
of the same type is inserted, the next configuration get used. In that way multiple
configurations may be
available for the same devices. Also for e.g. bridges, the configurations (!) of the
devices behind the bridge
are added together and the bridge is configured using those resource windows. This
means that the user may
have configurations for 6 devices in the configuration area, actually no device
attached, but still the bridge is
configured to be able to hold all of those devices making it fully hotplug able.
Now also if a configuration for a fixed device (e.g. NIC) is found but not used during
bootup, it will get marked
as obsolete (in detection area). Now the *user* will get a prompt that the card was
removed and what should
be done to the configuration. If he doesn't remove it, this configuration will stay on
the system in configuration
area and the user won't get asked again (only if he chooses to). This means removing a
NIC, powering on the
computer, powering down, inserting NIC will make the OS not forget about the
configuration, but use the old
(already defined) one (if it's still possible). If the configuration fails, the card
stays disabled and the user will get
asked for a new configuration. It's also not limited to the slot, where you insert a
card.
The main design was to make a generic interface, so that one daemon is able to
configure all devices in the
system in a generic manner, not automatically but including the user to accept certain
new configurations and
also manually modify them, but making it impossible for the user to trash the system
(to a certain degree). The
only thing that is able to get "used" by other drivers is the GCONFIG-API, but it
doesn't have to be used. You
may use resource manager as well. Or OEMHLP$, or whatever you want.
If you want it simple: It's there to configure unconfigured cards and/or reconfigure
cards, but not the Windows
way. This was the main design goal.
>>>>Tuple #6, code = 0x1b (Configuration entry), length = 7
>>>> 000: c0 81 18 45 30 fc be
>>>> Config index = 0x0(default)
>>>> Interface byte = 0x81 (I/O) wait signal supported
>>>> Card decodes 5 address lines, limited 8/16 Bit I/O
>>>> IRQ modes: Level
>>>> IRQs: 2 3 4 5 6 7 9 10 11 12 13 15
>>>>^^^^^
>>>>I bet bit-encoded design.
>>>Forget about this IRQ stuff. IRQ routing takes place in the
>>>PCCard/Cardbus bridge. The client driver simply sets up a bit field
>>>with all acceptable (by the driver, which should be any !) IRQ lines
>>>and card services will return an appropriate one.
>>look above. I need to support and include those fields into proposal areas into
>detection area.
>No, you don't! Did you ever write a PCCard/Cardbus enabled driver? I
>have limited knowledge on Cardbus, but may be Veit will fill the void.
I need to know how many resources a device needs, otherwise I can't adjust the
resource window.
That's why I'm putting all resource requirements of a certain device into detection
area.
>>On normal (non-PCI) PCMCIA controllers -> yes you are right. The driver will do it.
>On cardbus, there is this
>>resource window crap, so it's not do-able by the actual cardbus driver. The cardbus
>driver needs to get
>>configured on system startup, not later. And the window may not get adjusted.
>Where did you learn that from?
Well, if I change the resource window during run-time, I would need to reconfigure the
PCMCIA devices, don't
I?
(talking about cardbus again)
e.g. I/O resource window is 0xE400 -> 0xEFFF
1 card is inserted at system startup and takes up all the space. Also another PCI
device sits at
0xE000->0xE3FF. User inserts new card. What should I do now? I can not enlarge the
window in any way, so
I would need to adjust it to e.g. 0xD000 -> 0xDFFF. But there is already a card using
the 0xE400 resources,
so I can't change it. I would need to also reconfigure the 1st cards resources. If the
driver is point-enabled,
then it actually thinks the device is fixed...fixed at 0xE400. So if I change the
window, the first card would
stop to work.
If I'm wrong with this, I'm sorry.
>>>>I understand Config Index. If it's 0, it has to get included in any configuration.
>>>No. Default configuration tuples (there my be many!) are indicated by
>>>some bit. These defaults may be modified by subsequent, non-default
>>>config tuples on a per-tuple basis. Example: the default tuple
>>>describes a full configuration, while subsequent non-default tuples
>>>modify just a single entry (like an IO range) keeping the rest as
>>>described in the default tuple.
>>So this means one tuple per configuration index?
>Yes.
So it's pretty easy. At least easier than PnP.
cu, Kiewitz
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
