AlexeyBogoslavsky
Tue Feb 05 08:47:03 CST 2008
Hi,
I don't think the test has any problem with the driver being installed, even
if it doesn't need it - it knows when to stop it and eventually tries to
restart it.
But, anyway, the problem we are experiencing obviously doesn't have anything
to do with the driver. Rather, it's all about what we do in the firmware:
whether we allow the adaptor to be put in D0 by merely writing the value of 0
into the corresponding register (and then we're doomed to fail the PCI test),
or whether we disallow that and then have another problem, namely we're
incapable of starting the driver when the card is in D3 - unlike all other
cards. So what I'm looking for is how we combine the correct behavior upon
startup with the ability to pass the PCI test.
Regards,
Alexey
"DaveH" wrote:
> As far as I know all PCI compliancy tests shall be run without any drivers
> installed. Our test department has made this mistake of having drivers
> installed quite few times; are you sure you need drivers when running the
> test?
>
> Sahand
>
> "Alexey Bogoslavsky" wrote:
>
> > Hi, and thanks for the answer!
> >
> > If it's the PCI bus driver that's supposed to put the card in D0, then what
> > technique does it use to do so? Does it simply write the value of 0 to the
> > corresponding register in the card's configuration space?
> >
> > But then there's something very basic I don't seem to understand.
> > When we allow putting the card to D0 by simply writing the value to the
> > register in the configuration space, we fail the pci compliance test
> > (PciTest2_1) that gives the following error message:
> >
> > Error: 0x0, Error 0x00000000
> > FAIL: 4.62.3 - The PowerState field of the PMCSR must retain a D3
> > value (11b) when written.
> > File=d:\3627t\testsrc\basetest\pnp\pci\pcitest2.1\exe\pm.cpp Line=527
> >
> > So, we ignore writing to the register and only allow the adaptor to switch
> > to D0
> > when a certain bit in the control register is set before such write attempt
> > (which we could set from our driver when necessary). Obviously, this could
> > explain why the PCI bus driver fails to put us into D0. But how do we allow
> > this without failing the pci test?
> >
> > Thanks,
> > Alexey
> >
> >
> >
> > "Alireza Dabagh [MS]" wrote:
> >
> > > It is not RealTek driver. PCI bus driver puts the adapter in D0.
> > >
> > > Have you seen your MiniportInitialize called when your device is in low
> > > power state?
> > >
> > > -ali
> > >
> > > --
> > > This posting is provided "AS IS" with no warranties, and confers no rights.
> > >
> > >
> > > "Alexey Bogoslavsky" <Alexey Bogoslavsky@discussions.microsoft.com> wrote in
> > > message news:F264BA07-9604-459E-8C98-38A79B64C694@microsoft.com...
> > > > Hi, all
> > > >
> > > > I'm currently implementing the power management logic in the NDIS miniport
> > > > driver of our PCI wireless card. We would like our driver to make sure the
> > > > card is in D0 state during the driver initialization. But there seems to
> > > > be a
> > > > problem. Obviously, I can't access our PCI configuration space in
> > > > DriverEntry, since at this stage the driver doesn't even know what devce
> > > > it's
> > > > going to work with, let alone having its configuration space mapped. I
> > > > thought I'd take care of the transition to D0 in our MiniportInitialize
> > > > callback, but the thing is this callback is not even called when the card
> > > > happens to be in D3 state upon drier initialization.
> > > >
> > > > I used a debugger to see what other NDIS drivers do. I've found out that,
> > > > for instance, when the DriverEntry function of RealTek 8139 card's driver
> > > > (also NDIS 5.1. based) is called, the device is always in D3 state (I used
> > > > !pci command of WinDbg to examine the card's PCI configuration space).
> > > > Then I
> > > > set breakpoints on every callback function registered by the call to
> > > > NdisMRegisterMiniport from DriverEntry. The first callback to be called
> > > > was
> > > > InitializeHandler and, somehow, by the time it was called the card's power
> > > > state had already been changed to D0! I wonder what and how caused this to
> > > > happen, as this is precisely what I need my driver to be capable of doing.
> > > >
> > > > I do believe I could achieve this in a NDIS 6.0 driver - probably,
> > > > providing
> > > > an optional handler for AddDevice IRP would give me an appropriate context
> > > > for writing to the configuration space causing the device to switch to D0.
> > > > But I really have no idea how this could be done in an NDIS 5.1 driver.
> > > > Yet,
> > > > this is precisely what the RealTek 8139 driver manages to pull off.
> > > >
> > > > Any help on the issue will be highly appreciated.
> > > >
> > > > Regards,
> > > > Alexey
> > > >
> > >
> > >