On Tue, 31 Dec 2002 13:17:25 +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 ?
>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).
>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.
>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).
>I propose that I will include an API for HWDevice generation, so one will have to
>include support for
>GCONFIG into AUTOCFG2.SYS driver(s). I don't see any other way, especially because of
>the driver
>configuration choosing.
>
>Tuple #3, code = 0x20 (Manufacturer ID), length = 4
> 000: 49 01 ab c1
> PCMCIA ID = 0x149, OEM ID = 0xc1ab
>^^^^^^
>This would get put into Vendor/DeviceID in BASE-Block.
>
>Tuple #4, code = 0x15 (Version 1 info), length = 26
> 000: 04 01 45 74 68 65 72 6e 65 74 00 41 64 61 70 74
> 010: 65 72 00 32 2e 30 00 ff 00 ff
> Version = 4.1, Manuf = [Ethernet], card vers = [Adapter]
> Addit. info = [2.0]
>^^^
>All strings will get appended on each other and put into NAME-SubBlock (like for PnP).
>Version will get put into Version/Revision bytes in BASE-Block.
>
>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.
>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.
>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.
>If no one in here has a full tuple documentation, I will go into a library and look
>for
>the info.
I have some official specs (very old, version 2) in the company that I
work for. And I have the latest Mindshare books on PCCard and Cardbus
in the company as well.
>I looked at the official specs and they are priced at 500$ (!!) crazy. I couldn't
>find anything quite
>useful (i mean fully documented, not some crazy l33t linux super-source w/o comments).
>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.
>Otherwise it's selected by the
>driver. e.g. all resource requests with index 0x1 get used when configuration 1 is
>selected.
I seriously recommend to have a look into the source that I sent
recently. It does all this stuff.
>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.
>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.
Ciao
Dani
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
