Issues with schizophrenic devices (fyi)(转)

好象不是本版的，不管了.
I brought to our PNP developer\'s attention nasty driver design issues people
are running into with reprogrammable PCI (FPGA/DSP) and USB devices.  We saw
couple of those in recent days (Triggering a PCI bus re-scan)  in this
forum. Here is his response:

**********************
Our customer needs to be warned that this type of hardware may not be
productizable.

The design (a reprogammable PCI FPGA chip that disappears and reappears as
another device) is similar to some of the USB programmable DSP designs we\'ve
also seen problems with. Both of these designs run into major problems with
PnP and Power Management.

Problems

--------

Identification

- In its default state, the device usually exposes generic \"DSP/FGPA\" IDs.
An INF targets those IDs and specifies a driver that\'ll transform the
hardware into something else. If two different hardware vendors each use the
same reprogrammable chip, their INFs will both match against the same
DSP/FGPA IDs. The OS doesn\'t know which driver to pick. Even better, insert
a card from each vendor - mayhem ensues as one of the cards will get the
wrong payload.

Power Management

- During power management operations (hibernation, suspend, etc), all power
is often removed from the chip. When this happens, the chip typically loses
its new identity and reverts back to its DSP/FPGA form. To the OS, this
appears to be a surprise removal (the card disappeared). All the handles
opened by applications against the device will go dead. The application
might reestablish contact when the original device appears to be
\"reinserted\", ie the load sequence has repeated, but there is no gaurantee
of this.

Plug and Play

- Some Plug and Play operations may result in power loss (rebalance),
leading to the problem above. Updating the driver also temporarily places
the hardware in D3. Depending on the bus, this may result in a state loss,
causing the device to \"disappear\" just as the OS is planning to reload the
new drivers. A reboot popup may result from this.



How To Make FGPA/Reprogrammable-DSP Designs Work

------------------------------------------------

The best designs simulate a bridge/hub with devices behind it. For instance,
the following design of a PCI FGPA works properly with Windows: 1. The PCI
FGPA simulates a PCI-to-PCI bridge. 2. The PCI FGPA logic retrieves the IDs
for the bridge from an EEPROM, ensuring no possible overlap with other
customers using the same chip (the IHV is expected to contact the PCI SIG
and retrieve such IDs.) 3. The INF for the FGPA specifies PCI.SYS as the FDO
(using NEEDS and INCLUDE directives to reference machine.inf as needed), and
specifies a lower filter driver that will deliver the payload. 4. During
IRP_MN_START_DEVICE, the filter driver downloads the payload to the FPGA.
The FPGA now appears as a bridge (same IDs) with a *child* behind it. The
child represents the IHV\'s device. 5. After start, the OS enumerates the
bridge. Since the child is present, the OS loads the next set of drivers. 6.
During powerup from suspend or hibernation, the OS first powers up the
bridge. The filter driver takes this opportunity to reapply the payload if
necessary.

Here is a similar design for a reprogrammable USB chip:

1. The USB chip simulates a hub.

2. The USB chip retrieves the Vid/Pid IDs for the hub from an EEPROM 3. The
INF specifies USBHUB.SYS using NEEDS and INCLUDE directives targeting
USB.INF. The INF also specifies a special lower filter driver to download
the payload. 4. During IRP_MN_START_DEVICE, the filter programs the USB chip
to appear as a hub with a device behind it. 5. After start, the OS
enumerates the hub and discovers the child.

6. During powerup, the OS always powers up the hub before the child. The
filter reapplies the payload during hub powerup.

And another USB design:

1. The USB chip simulates a *composite* USB device.

2. The USB chip retrieves the Vid/Pid IDs for the hub from an EEPROM 3. The
INF specifies USBGCCP.SYS via NEEDS and INCLUDE directives (similar to
above).

4. During IRP_MN_START_DEVICE, USBGCCP will read descriptors from the
hardware to determine which functions are exposed by the composite device.
The driver (a lower filter) would reprogram the hardware to specify child
during Start, before the IRP reached USBGCCP.

5. During powerup, the driver would reapply the payload as needed.


--
-Eliyas
This posting is provided \"AS IS\" with no warranties, and confers no rights.