In message <[EMAIL PROTECTED]> Mike Smith writes:
: > : Let's be realistic; the right way to do this is going to be to use the
: > : ivar interface; cardbus_get_cistuple(dev, index) just like all the other
: > : PCI bus accessor functions. PCI will just need to pass the request
: > : through to its parent, assuming its parent is a cardbus bridge, or veto
: > : it otherwise.
: > Why does this have to go even to the bridge?
: Because it's the bridge driver that has to parse the CIS; it needs it to
: eg. set power and so forth. And because the bus code should be generic.
I don't think that the bridge driver should parse the CIS. The bus
driver should do the parsing. The bridge driver may be asked by the
bus driver to do mapping and such, but it shouldn't do the parsing of
the CIS. This is a card services vs socket services issue. I want to
be able to implement card services and socket services (maybe in a
form different than the pccard spec states).
Other card services, from the spec, include resource management (which
the bus does), cis traversal, bulk memory services, cis verification,
and event managment (note that socket services generate these events
and card services respond to them) and some power management issues.
All the flash MDTs are handled here as well. Many of these are unique
to cardbus and pccard. Many of these are shared with pci. The
mapping into FreeBSD's newbus has been a little fuzzy.
The experience from the 16-bit days was that one can have different
PCIC bridges that the pccard bus sits on top of. There are at least 4
different APIs to talk to the pcic bridge that I know of (pcic
(i82365), pcic98 (a custom NEC part found on some pc98 laptops
(including mine!)), tcic (an 8-bit pccard interface) and some sbus
chip that I know nothing about). We don't want to have the CIS
parsing code replicated in each one. While there is only one known
cardbus bridge API today, I don't want to architect something that
will be hard to have a different one should it become necessary if
there's a cardbusII bridge based on pcix that has a legacy way to
support cardbus1 (for example).
: > The cardbus bus code
: > already deals with the CIS and it should be the one to arrange things
: > to happen. We can tweak the current cardbus CIS reading stuff to do
: > this and maybe combine it somewhat with the pccard CIS reading stuff.
: > Also, the index doesn't make so much sense because each CIS entry is a
: > variable length, so we'd have to walk the chain.
: Index is the tuple index, not the byte offset in the CIS; sorry I didn't
: make that clear.
I'm not sure that I follow what you mean by tuple index then. Is that
the Nth CIS, or the CIS of type N? If it is the Nth cis, then we do
have to walk N-1 CIS tuples to find it. If it is the CIS of type N,
then how do we do multiple ones of type N (which is legal and happens
for the config entries)?
The CIS is an array of bytes. It lives in 1 or more address spaces.
Each CIS tuple contains a length (which is used to find the next one).
Some CIS tuples are multi-function chaining tuples and contain two
lengths, one of the current CIS tuple, and the aggregate length of all
tuples for this function. I do not recall if there's a function
number in it, but that is implicit from where we are in the CIS. Each
CIS tuple is between 2 and 254 bytes long. To find the Nth one, I
have to know where the N-1th one ends for all values of N > 0. The
0th element is pointed to by the CIS pointer in the pci config space.
: > Also, this isn't a PCI thing, so no PCI code should be called. :-)
: Interrupts aren't a PCI thing either, but we pass attempts by PCI drivers
: to do stuff with them up through the stack. This really isn't any
I do think it is different, but maybe we're arguing about semantics
here. I'm talking about having the cardbus bus (cardbusN) code do the parsing
of the CIS, while asking for assistance from the cardbus bridge code
(pccbbN) to apply power to the slot, map in address spaces, etc. The
carbus bus code can generically parse the CIS and dole it out to its
children by asking the bridge to do certain specific things. The
bridge shouldn't be doing the actual parsing. This is a layering
argument. The bus is where the resource allocation book keeping takes
place, and we'd need it to do that for the CIS stuff that has been
mapped so that if the card driver is a bad citizen, it can cleanup
I guess I fear putting the cardbus bus function in the cardbus bridge
and teaching a regular pci bus to pass them through. I'd rather have
the pci bus code reject such attempts and the cardbus bus code process
: I think that you're overrating the things that need to be "shoehorned"
: into PCI to make it a comfortable superset of stock PCI + hot-plug PCI +
: CardBus. So far all we have is passing through a CIS tuple accessor
: function. 8)
It isn't just an accessor to a configuration space, like PCI has. It
is access to a byte stream that may live in many different spaces,
even on the same card (this was true of 16-bit cards, I'm not sure of
the 32-bit cards). Again, we have a disagreement about where the
parsing should rightly be done and where information about the state
of the parsing and resouce maps should be cached.
These tuples aren't like PCI configuration space. That makes sense to
have at the bridge level because no parsing is necessary. The
accessors for the CIS just don't make sense because the CIS tuples are
variable length and are more expensive to map in and out than the pci
configuration space. The CIS is also read-only, whereas the pci
config space is read/write to configure the card. The attribtue
memory for 16-bit cards can be written to and is usually where the CIS
lives, but that's something altogether different.
Maybe I'm not explaining well, or maybe there are issues here that I
don't understand. I am finding it hard to understand exactly what you
are suggesting at times. I think I have it, but it just doesn't make
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message