/*
* CDDL HEADER START
*
* The contents of this file are subject to the terms of the
* Common Development and Distribution License, Version 1.0 only
* (the "License"). You may not use this file except in compliance
* with the License.
*
* You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
* See the License for the specific language governing permissions
* and limitations under the License.
*
* When distributing Covered Code, include this CDDL HEADER in each
* file and include the License file at usr/src/OPENSOLARIS.LICENSE.
* If applicable, add the following below this CDDL HEADER, with the
* fields enclosed by brackets "[]" replaced with your own identifying
* information: Portions Copyright [yyyy] [name of copyright owner]
*
* CDDL HEADER END
*/
/*
* Copyright 2005 Sun Microsystems, Inc. All rights reserved.
* Use is subject to license terms.
*
* Derived from pseudocode supplied by Intel.
*/
#pragma ident "%Z%%M% %I% %E% SMI"
/*
* Workaround for Intel Orion chipset bug
*
* It is intended that this code implements exactly the workaround
* described in the errata. There is one exception, described below.
*/
#include <sys/pci_cfgspace_impl.h>
static int ncDevNo;
{
int Num82454 = 0;
int BusNo = 0;
int FunctionNo = 0;
int DeviceNo;
/* Found 82454 PCI Bridge */
Num82454++;
if (RevisionID <= 4) {
}
/*
* c82454 Found - determine the status of
* inbound posting.
*/
if (PciReg & 0x01) {
}
} else {
/* nc82454 Found - store device no. */
}
}
} /* DeviceNo */
/*
* Determine if nc82454 posting is to be enabled
* and need of workaround.
*
* [[ This is a deviation from the pseudocode in the errata.
* The errata has mismatched braces, leading to uncertainty
* as to whether this code is inside the test for 8086/84c4.
* The errata has this code clearly inside the DeviceNo loop.
* This code is obviously pointless until you've at least found
* the second 82454, and there's no need to execute it more
* than once, so I'm moving it outside that loop to execute
* once on completion of the scan. ]]
*/
/* Enable inbound posting on nc82454 */
PciReg |= 0x01;
pci_mech1_putb(0, ncDevNo, 0,
} else {
}
return (A2B0WorkAroundReqd);
}
/*
* When I first read this code in the errata document, I asked "why doesn't
* the initial read of CFC (possibly) lead to the 'two responses' problem?"
*
* After thinking about it for a while, the answer is that we're trying to
* talk to the nc82454 itself. The c82454 doesn't have the problem, so it
* will recognize that this request is *not* for it, and won't respond.
* The nc82454 will either respond or not, depending on whether it "saw"
* the CF8 write, and if it responds it might or might not return the
* right data. That's all pretty much OK, if we're willing to assume
* that the only way that 84C48086 will come back is from the vendor ID/
* device ID registers on the nc82454. This is probabilistic, of course,
* because the nc82454 *could* be pointing at a register on some device
* that just *happened* to have that value, but that seems unlikely.
*/
static void
{
do {
} while (test != 0x84c48086UL);
/*
* At this point we are guaranteed to be pointing to the nc82454 PCI
* bridge Vendor ID register.
*/
do {
/*
* Impact of the erratum is that the configuration read will
* return the value which was last read.
* Hence read register 0x54 until the previous read value
*/
} while (test == 0x84c48086UL);
/*
* At this point we are guaranteed to be pointing to the PCI
*/
PciReg &= ~0x01;
}
static void
{
PciReg |= 0x01;
}
{
return (val);
}
{
return (val);
}
{
return (val);
}
void
{
}
void
{
}
void
{
}