RE: Multifunction devices

[Lame Brooks-G14738 <brooks.lame@motorola.com>]

Good point, should post it to the list   :)    -- BrooksL

> -----Original Message-----
> From: Patrick Maupin [mailto:pmaupin@jump.net]
> Sent: Friday, 26 May, 2000 13:42
> To: Lame Brooks-G14738
> Subject: Re: Multifunction devices
> 
> 
> I don't know about the other platforms, but when an x86 CPU
> performs a configuration cycle using the type 1 mechanism, the
> only indication it gets of a master abort is that all FFs are 
> returned.
> 
> So from the configuration program's perspective, a device which
> does not claim a config cycle is indistinguishable from a device which
> claims the cycle, but returns all FFs.
> 
> I think this is the intent, from the hardware perspective.  It is much
> simpler to claim all configuration cycles when your IDsel is active
> than it is to qualify IDsel with other address bits.
> 
> Most BIOSes probably won't get too confused if all configuration
> addresses within a particular function within a device are all
> hardwired to zeroe, because that means there are no resources
> to be allocated (no active BARs).  But I don't know of any BIOS
> which could possibly get confused if the function's configuration
> registers all returned all FFs, because that is, in fact, the 
> value the
> BIOS expects when "nobody's home."
> 
> In short, I wouldn't go to all the trouble to not claim the 
> configuration
> cycle, but I would make all the registers return all ones rather than
> all zeroes, unless somebody else can point out where the spec says
> this is a bad practice.
> 
> Pat Maupin
> 
> Lame Brooks-G14738 wrote:
> 
> > Sorry for using an ambiguous term - didn't realize PC98 
> gave it a specific
> > definition.  I use 'ghost' to refer to something that 
> appears to be there,
> > but is not functional.  For this case, refer to the PCI 
> Compliance Checklist
> > (available from www.pcisig.com), item CO13: "If the device 
> is multifunction,
> > are config space accesses to unimplemented functions 
> ignored?"  This is also
> > pointed out in the PCI Compliance Workshop presentations 
> under "PCI Do's and
> > Don'ts (Mostly Don'ts)".  Yes, I realize "ignored" might be 
> debated, but if
> > you assert DEVSEL#, aren't you  responding by claiming the cycle?
> > -- BrooksL
> >
> > > Actually, I believe (technically) this mistake does not meet
> > > the definition
> > > of a ghost device.  The description of a ghost device that
> > > was shown in the
> > > PC98 spec follows:
> > >       "A computer must not include any ghost devices, which
> > > are devices that do not
> > > decode the type 1/type 0 indicator. Such a device will appear
> > > on multiple PCI
> > > buses."
> > >
> > > The mistake we made will not show up on other buses, instead
> > > there will be config
> > > spaces present where there is no device.
> > >
> > > (I'll admit that this isn't the "right" way to deal with
> > > this.  The "right"
> > > way is to simply fix it.  But engineering is a discipline
> > > full of trade-offs
> > > between what is "right" and what is expedient.)
> > > Thanks,
> > > Dahlin
> > >
> > > >If I recall correctly, 'ghost' config spaces on 
> multifunction devices
> > > >violates the PCI spec and PC'99 requirements.  This problem
> > > is should not be
> > >
> > > >expected in any new silicon.
> > > >-- BrooksL
> > > >
> > > >> -----Original Message-----
> > > >> From: dahlin@wa.freei.net [mailto:dahlin@wa.freei.net]
> > > >> Sent: Thursday, 25 May, 2000 02:22
> > > >> To: pci-sig@znyx.com
> > > >> Subject: Multifunction devices
> > > >>
> > > >>
> > > >> We have a custom IC that just had first silicon show up in
> > > >> our lab.  It is a
> > > >> multifunction device with two functions.  So far we have
> > > >> found one problem in
> > > >> the PCI interface
> > > >>
> > > >> That problem is that the device issues a DEVSEL# for config
> > > >> space accesses to
> > > >> all 8 possible functions.  The result is that we have 2
> > > >> functioning config spaces
> > > >> and 6 config spaces that have read-only registers that
> > > contain 0's.
> > > >>
> > > >> This is not a good thing, but I think it is a problem that
> > > >> can be lived with.
> > > >>  The BARs return all 0's when read so the system won't
> > > >> allocate any space to
> > > >> the 6 extra devices, and we won't conflict with any other
> > > >> config spaces.
> > > >>
> > > >> Does anyone see a problem with not spending the time and
> > > >> money on fixing this
> > > >> if it remains that only bug?
> > > >>
> > > >> Thanks,
> > > >> Dahlin
> > > >>
> > > >
> > > >
> > >
>