[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: PCI IDE programming byte
- To: Mailing List Recipients <pci-sig-request@znyx.com>
- Subject: FW: PCI IDE programming byte
- From: "Hajime Nozaki" <nzk@pc2.fc.nec.co.jp>
- Date: Fri, 12 Mar 1999 10:51:34 +0900
- Delivered-To: pcisig@teleport.COM
- Importance: Normal
- Resent-Date: Thu, 11 Mar 1999 18:12:40 -0800
- Resent-From: pci-sig-request@znyx.com
- Resent-Message-ID: <"oBxYO1.0.SM.X97ws"@electra.znyx.com>
- Resent-Sender: pci-sig-request@znyx.com
Probably, I sent incorrect address.
So, I re-send this mail.
---------------------------------------------------------------
Hajime Nozaki Strategic Technology Development Group
2nd Personal Computers Division
NEC Corporation
E-mail : nzk@pc2.fc.nec.co.jp
Phone : +81-423-33-1303 Fax : +81-423-33-1447
NEC Phone : 23-33580 NEC Fax : 23-33599
-----Original Message-----
From: Hajime Nozaki [mailto:nzk@pc2.fc.nec.co.jp]
Sent: Friday, March 05, 1999 8:39 PM
To: Pierre-Yves Santerre; Mailing List Recipients
Subject: RE: PCI IDE programming byte
Hi, Pierre.
How about Windows 2000?
Does Win2K also read above 40h config register, and load device
specific driver?
---------------------------------------------------------------
Hajime Nozaki Strategic Technology Development Group
2nd Personal Computers Division
NEC Corporation
E-mail : nzk@pc2.fc.nec.co.jp
Phone : +81-423-33-1303 Fax : +81-423-33-1447
NEC Phone : 23-33580 NEC Fax : 23-33599
> -----Original Message-----
> From: Pierre-Yves Santerre [mailto:pierreys@MICROSOFT.com]
> Sent: Thursday, March 04, 1999 4:24 AM
> To: Mailing List Recipients
> Subject: RE: PCI IDE programming byte
>
>
> Sorry for the delay.
>
> Indeed, Microsoft tried to make this a standard. The problem we are
> addressing is that, in legacy mode, there is no way to know whether a PCI
> IDE controller really has an enabled primary and/or secondary channel.
> Poking at 1f0/170 does not work as the channel could come from some other
> IDE controller. Assuming it is present would cause potential
> false conflict
> on IRQ 14 or 15 (in legacy mode, these are treated as edge triggered
> non-sharable). We can take the hint that if bit 3 is set, the secondary is
> probably enabled, but that heuristic fails rather often.
>
> Most chipset have proprietary ways (read: in above 0x40 config space) of
> knowing whether the channels are enabled. That is rather bad
> since it means
> we need to load a device specific driver first. But given the failure to
> convince the SIG, we had no other choice. So for any new
> VenID/DevID PCI IDE
> that can have a channel disabled, you must also provide windows 9x with a
> miniport driver to return those two enable bits (or at least the
> instance of
> an exiting one).
>
> Given that some OEMs elected to use our recommended method, we did include
> it in our built-in miniport driver, as instance 3.
>
> Pierre-Yves Santerre
> Win9x PnP Architect
>
> > -----Original Message-----
> > From: Dan Mick [SMTP:dan.mick@West.Sun.COM]
> > Sent: Tuesday, March 02, 1999 2:54 PM
> > To: Mailing List Recipients
> > Subject: Re: PCI IDE programming byte
> >
> >
> > > Date: Mon, 1 Mar 1999 18:45:39 -0800 (PST)
> > > From: Dan Mick <dmick@cypress.west.sun.com>
> > > Subject: PCI IDE programming byte
> > > To: pci-sig@znyx.com
> > >
> > > Regarding the byte of PCI configuration space that holds
> > > "programming info" for IDE controllers (the byte at address
> > > 09):
> > >
> > > I see definitions for bits 3-0 in PCI 2.1. Bit 7 is defined
> > > in a Bus Master IDE Controller specification. Bits 6-4 are
> > > defined to be 0's in PCI 2.1.
> > >
> > > And of course we have an IDE controller that has nonzero bits
> > > in bits 6-4. Anyone have any idea whether that's simply a
> > > mistake, or are they supposed to mean something in some
> > > third spec somewhere?
> >
> > Apparently there was once some Microsoft proposal about
> > these bits (found in an Acer Labs, Inc. chipset doc):
> > bit 6 means "bits 5 and 4 are valid", and bits 5 and 4 are
> > 1 - enabled / 0 - disabled as a way for the OS (and BIOS?)
> > to enable or disable the secondary and/or primary channels
> > on this PCI dual-channel controller. Thus, the device
> > we're looking at starts with all three bits set to 1.
> >
> > I can't find any record of the MS proposal, or any indication
> > that it's made its way into PC99 or the HCT. Does anyone else
> > have any other info?
>
>