[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: PCI IDE programming byte



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?
>
>