On Tue, Nov 21, 2000 at 01:28:46PM -0700, Justin T. Gibbs wrote:
That's what I mean. You call this, and it will remap the CIS (if it
has been unmapped), walk it for you and pass you a pointer to each CIS
entry one at a time to the function you specify.
Warner
I'd rather have a seek/read
In message [EMAIL PROTECTED] Jonathan Chen writes:
: As I see it, there are several ways this can be implemented, with several
: issues to consider.
: 1) How is the information passed?
:a) callback
:b) driver code calling cardbus_get_cistuple(dev, tuplenum)
Yes. I think there's a strong
The other interface will be an enumerative interface where you can get
a callback for each CIS entry. These will be bus method based so that
they will be the same between 16-bit and 32 bit code.
I don't think the enumerative interface should be callback based. I'd
rather have something that
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes:
: The other interface will be an enumerative interface where you can get
: a callback for each CIS entry. These will be bus method based so that
: they will be the same between 16-bit and 32 bit code.
:
: I don't think the enumerative
That's what I mean. You call this, and it will remap the CIS (if it
has been unmapped), walk it for you and pass you a pointer to each CIS
entry one at a time to the function you specify.
Warner
I'd rather have a seek/read interface than have a callback.
--
Justin
To Unsubscribe: send mail
The problem with a read/seek interface is that you are consuming a
resource (a memory window) while you are using it.
Yes, but this is the client's resource to use anyway.
You'd need an
open/close on top of that as well to properly map things in to start
and then free them at the end. Plus you
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes:
: The problem with a read/seek interface is that you are consuming a
: resource (a memory window) while you are using it.
:
: Yes, but this is the client's resource to use anyway.
IIRC, it is shared at the bridge, so the client driver needs
That's what I mean. You call this, and it will remap the CIS (if it
has been unmapped), walk it for you and pass you a pointer to each CIS
entry one at a time to the function you specify.
Warner
I'd rather have a seek/read interface than have a callback.
Let's be realistic; the right
IIRC, and I haven't looked it up, the CIS entries that would be
problematical have two next pointers. One is for the next function,
while the other is for the first entry specific to this function. The
driver code could look at the CIS entry to tell what to do, and if it
was the wrong
In message [EMAIL PROTECTED] Mike Smith writes:
: That's what I mean. You call this, and it will remap the CIS (if it
: has been unmapped), walk it for you and pass you a pointer to each CIS
: entry one at a time to the function you specify.
:
: Warner
:
: I'd rather have a seek/read
: 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
In message [EMAIL PROTECTED] Mike Smith writes:
: No; the CIS parser should know which function it's being called on behalf
: of, and simply elide the tuples that don't relate to that function.
This isn't always the right thing to do. At least in the 16-bit
world, there are drivers that want
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
In message [EMAIL PROTECTED] Mike Smith writes:
: No; the CIS parser should know which function it's being called on behalf
: of, and simply elide the tuples that don't relate to that function.
This isn't always the right thing to do. At least in the 16-bit
world, there are drivers that want
In message [EMAIL PROTECTED] Mike Smith writes:
: No; the CIS parser should know which function it's being called on behalf
: of, and simply elide the tuples that don't relate to that function.
This isn't always the right thing to do. At least in the 16-bit
world, there are drivers that
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes:
: The ROM BAR is only implemented for function 0 and the ROM
: contains information for all functions of the chip. So, functions
: greater than 0 must have the flexibility to activate at least the ROM
: BAR on function 0 as well as access
function its own CIS chain. These CIS chains can live in
configuration space, in memory space or the expansion ROM (which I
assume is the same thing as the ROM BAR on function 0, but maybe I'm
mistaken) and the bridge is responsible for properlly mapping the last
two.
The config space
In message [EMAIL PROTECTED] Bill Paul writes:
: Is there any support planned for externalizing the CIS info somehow,
: i.e. by providing bus methods to call the CIS parsing routines? Another
: way to do it would be to pass the info down to the child device using
: ivars. I would imaging that
18 matches
Mail list logo
