On Tue, 31 Dec 2002 19:07:37 +0100 (CET), Jimi 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?!
Of course. A window of minimum size.
>>>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.
Oops, you are right.
>>>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.
>>IIRC I found some quite good documentation by a Google search (I think
>>it was from Solaris).
>
>Where can I get it?
I can't remember.
>>>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.
BTW, this is preparsed by card services and available in the
GetConfiguration structure, and many more tuples are as well.
>>>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.
>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.
>>>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.
>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?
>>>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.
Ciao,
Dani
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
