On Tue, 31 Dec 2002 18:44:47 +0100 (CET), Daniela Engert wrote:
>>Some PCMCIA cards may request e.g. I/O region 0x330h.
>??? This is just a single IO register. What's the problem ?
I would need to have a window for it?!
>>That's okay on PCMCIA controller (the old ones,
>>16-bit). But what happens on Cardbus? I only have 2 memory and 2 I/O windows.
>You have 4 BARs (IO or MEM) per socket (== PCI function).
I'm talking about the cardbus controller.
And that one only has 2 memory and 2 I/O windows. At least afaik after reading Ralph
Browns interrupt list:
1Ch DWORD memory base address 0
20h DWORD memory limit 0
24h DWORD memory base address 1
28h DWORD memory limit 1
2Ch WORD I/O base address 0
2Eh WORD I/O base address 0 high word (optional)
30h WORD I/O limit 0
32h WORD I/O limit 0 high word (optional)
34h WORD I/O base address 1
36h WORD I/O base address 1 high word (optional)
38h WORD I/O limit 1
3Ah WORD I/O limit 1 high word (optional)
>>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.
>>I would really appreciate some details on those tuples. I'm able to find out much
>about the (pretty simple)
>>format, but I need some real documentation especially for resource tuples and the
>"link-tuples".
>IIRC I found some quite good documentation by a Google search (I think
>it was from Solaris).
Where can I get it?
>>Tuple #12, code = 0x21 (Functional ID), length = 2
>> 000: 06 00
>> Network/LAN adapter
>>^^^^^
>>This would get put into Class and Sub-Class bytes in BASE-Block
>This tuple is likely to be missing.
Not a problem. If it's not there, the default is used which means 0 for
class&sub-class. This means actually no
class and no sub-class.
>>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. 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).
>>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.
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.
>>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?
>>I propose to generate multiple PROPosal blocks. One per configuration. So if a
>device has 2
configurations, it
>>will have 2 PROPosal blocks and the default requirements are listed in *both*.
>Fine. But remove blocks which can's succeed because of resource clashes
>with other parts of the system.
That's not the way it's supposed to work. When I'm done with the detection area core,
I will explain the whole
design in detail. The detection area has nothing to do with the actual configuration
of any device. It contains
fixed information of devices that are attached to the system. The configuration area
is actually used for
resource assignment and that one contains the actual configuration per device that was
configured by the
user/daemon. In the PCMCIA case, I think every PROPosal sub-block would actually get
one configuration
sub-block in configuration area. If a configuration is seen as not possible, well I'm
not sure how to handle this
in detail. Setting a special bit would be possible or leaving that configuration in
there anyway, because it
wouldn't be allowed by resource manager anyway. (Resource assignments are coordinated
with resource
manager, so it's not possible to use a resource twice).
>>Tuple #13, code = 0x14 (No link), length = 0
>>^^^^
>>Another strange thing. I don't really know what those "links" are for. I would
>really appreciate some help.
>IIRC these are for multi function devices.
Would be great to have documentation on those, because it would be plain easy to
support those as well
(actually making multiple devices out of one actual PCMCIA device). This technique is
already being used on
PnP devices. My soundblaster card is actually detected as 3 individual devices.
cu, Kiewitz
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
