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 stron
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
> 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 sp
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 t
> >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
>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]> 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 t
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
> : 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:
: > >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
> 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
> >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;
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 ne
>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
In message <[EMAIL PROTECTED]> "Justin T. Gibbs" 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/r
>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
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 i
>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]> 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 th
Okay. Recently, David O'Brien handed me an Intel 10/100 Cardbus NIC,
which uses the 21143-PB chip. It's a non-MII card (has a Quality Semi
symbol PHY). Unfortunately, it looks like Intel has taken a few shortcuts
with this card: the serial EEPROM doesn't contain any useful information.
Instead, th
20 matches
Mail list logo
