RE: Responsibilty for enabling bus master enable bit?

[Brooks Lame <Brooks_Lame@mcg.mot.com>]

See comments below...

> Following the white paper about warm reset, to prevent 
> outstanding bus master
> requests from messing up memory during system boot, system 
> BIOSes can turn off
> the bus master enable bit in all devices and the option ROM 
> or drivers for
> the devices must turn them on again.

I don't think option ROMs should enable bus-mastering because I don't
know of an industry or defacto standard for a BIOS extension to reserve
a runtime RAM memory block ( I assume we are talking about X86 PC's).
Further, even if there was, this would be limiting because different
locations might be preferable for different OS.

> Now, suppose that a card vendor makes a card which consists 
> of a PCI-to-PCI
> bridge and a device behind that bridge.  Who is resposible 
> for turning on
> the bus master enable bit of the bridge?  Are all bridges 
> considered property
> of the system BIOS and so it must do it?  Or, is anything on 
> a plug-in card
> considered property of the card and so the option ROM must do it?

P2P bridges are a special case and have a control bit for asserting RST#
on the subordinate bus.  The BIOS or PnP OS (whoever owns the code for
interpreting a warm reset) should generate RST on all subordinate PCI
busses behind bridges.  The BIOS or PnP OS (whoever is enumerating and
configuring the PCI bus tree) can then enable busmastering on all P2P
bridges (it should still not enable busmastering on PCI devices because
that should be left up to the driver) Option ROMs should not touch a P2P
bridge unless it has special (uncommon) configuration requirements for
fixed devices behind it.  

> Sincerely,
> -Richard Walter
> rwalter@corp.auspex.com
> Note: I speak for myself, not for Auspex.

--
Brooks Lame'
Design Engineer,  Motorola Monterey Design Center
brooks_lame@mcg.mot.com,  blame@prolog.com
Standard Disclaimer: Editorial viewpoints are not necessarily those of
my employer.