LPC

On Nov 5, 2014, at 6:59 PM, xxxxx@gmail.com wrote:

Actually we are trying to control devices connected to EC (like turn ON/OFF relay ,LED’s ,keyboard etc).we have a set of commands given by EC design team to communicate with the same. this is the overall picture.microsoft provided driver is loaded for keyboard. but rest of the interfaces like relay(connected to GPIO) is not exposed in device manager. So i decided to load my driver on EC;but now as per your advise ,is not possible. So am thinking of what can be done to control those devices

What you have are child devices of the EC, right? That?s how you should abstract them. You modify your DSDT to create sub devices, and those sub devices can send ioctls into ACPI.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hi Tim
I googled and found EC code from NTDDK . Can i use that driver for my requirement??? …
Below is the DSDT entry for EC which was received from BIOS team

OperationRegion(LPC0, PCI_Config, Zero, 0xC0)
Field(LPC0, AnyAcc, NoLock, Preserve)
{
Offset(0x8), //Offset(8),
SRID, 8,
Offset(0x80), //Offset(128),
C1EN, 1,
Offset(0x84), //Offset(132),
}
Device(H_EC)
{
Name(_HID, EISAID(“PNP0C09”))
Name(_UID, One)
Method(_CRS, 0, NotSerialized)
{
Name(BFFR, ResourceTemplate()
{
IO(Decode16, 0x0062, 0x0062, 0x00, 0x01)
IO(Decode16, 0x0066, 0x0066, 0x00, 0x01)

})
Return(BFFR)
}
Method(_STA, 0, NotSerialized)
{
Store(One, ECON)
Return(0x0F)
}
Name(_GPE, 0x18)
OperationRegion(ECF2, EmbeddedControl, Zero, 0xFF)
Field(ECF2, ByteAcc, Lock, Preserve)
{
Offset(0xC6), //Offset(198),
BCC1, 16,
BTHV, 8,
Offset(0xD6), //Offset(214),
BTPL, 8,
BTPH, 8,
}
Method(ECMD, 1, Serialized)
{
If(ECON)
{
While(CMDR)
{
Stall(0x14)
}
Store(Arg0, CMDR)
Return(Zero)
}
Else
{
Return(0xFF)
}
}
Device(BAT1)
{
Name(_HID, EISAID(“PNP0C0A”))
Name(_UID, One)
Method(_STA, 0, NotSerialized)
{
If(And(BNUM, One))
{
Return(0x1F)
}
Return(0x0B)
}
Method(_BIF, 0, NotSerialized)
{
Name(xxx, Package(13)
{
Zero, 0x2710, 0x2710, One, 0xFFFFFFFF, 0x03E8, 0x0190, 0x64, 0x64,
“CRB Battery 1”, “Battery 1”, “Real”, “-Real Battery 1-”
})
If(ECON)
{

If(B1FC)
{

}
}
Return(xxx)
}

}
Name(IGDF, Zero)
Method(_REG, 2, NotSerialized)
{
If(LAnd(LEqual(Arg0, 0x03), LEqual(Arg1, One)))
{
Store(One, ECON)
If(LEqual(LSTE, Zero))
{
Store(Zero, ^^^GFX0.CLID)
}
If(LEqual(LSTE, One))
{
Store(0x03, ^^^GFX0.CLID)
}
Store(LSTE, LIDS)
Store(Zero, BNUM)
Or(BNUM, ShiftRight(And(B1ST, 0x08), 0x03), BNUM)
If(LEqual(BNUM, Zero))
{
Store(VPWR, PWRS)
}
Else
{
Store(RPWR, PWRS)
}
PNOT()
}
}
Method(_Q30, 0, NotSerialized)
{
P8XH(Zero, 0x30)
Store(One, PWRS)
PNOT()
}
Method(_Q31, 0, NotSerialized)
{
P8XH(Zero, 0x31)
Store(Zero, PWRS)
PNOT()
}

}
Device(BIND)
{
Name(_HID, “INT33D2”)
Name(_CID, “PNP0C40”)
Method(_STA, 0, Serialized)
{
If(LGreaterEqual(OSYS, 0x0D))
{
If(And(xxx, One))
{
Return(0x0F)
}
Else
{
Return(0x0B)
}
}
Return(Zero)
}
Method(_DSM, 4, Serialized)
{
Name(_T_0, Zero)
If(LEqual(Arg0, ToUUID(“xxxCF3C5-xxx-xxxx”)}))
{
If(LEqual(Zero, ToInteger(Arg1)))
{

}
}
Return(Buffer(One)
{
0x00
})
}
}

I couldn’t figure out how many interface EC exports . Can you plz help me out

Each _HID directive declares the hardware ID for one device. If you look back at the answer I provided on 19 Oct, I’m not sure what more info you need…

Peter
OSR
@OSRDrivers

Hi Peter
You have advised me that i can write a KMDF driver . But as per Tim (5th Nov 2014) , i cannot write KMDF driver for EC (either function or upper or lower filter driver) . And when i see the device manager , i see all the drivers are loaded by Microsoft . But our requirement is to control the devices connected to EC through ACPI commands. Thats the reason i shared the DSDT table for EC so that even if i had missed something, expert people like you and Tim would help me.

Sigh.

Let’s summarize, shall we?

  • You have some ACPI methods you want to invoke with the EC.
  • They’re part of the battery class stuff that’s in theEC
  • You want to know how to invoke these methods.

Is that a succinct description of your problem?

If so, Tim and I have answered this question at least two different ways… probably more.

Possibility 1:

  • Load a driver directly on the device (_HID) that contains the methods you want to invoke. If there’s a *real* Microsoft driver that claims this device (*not* an inf with “nodrv”… a REAL driver) then load as a filter of that real Microsoft driver.

Possibility 2:

  • Change the BIOS to export a private device that represents the functionality in the EC that you want to control, and load your driver on that device. Let me assure you, this is done all the time. We just finished a project here at OSR that does this. It’s really simple, as I explained back in my post two weeks ago.

Possibility 3:

  • Load your driver or filter on a *parent* of the device you want to control (something higher-up in the hierarchy of ACPI devices) and invoke your your method that way.

If the above options don’t make any sense to you, may I respectfully suggest that it is possible that you’re not sufficiently familiar with this particular area of Windows driver development to undertake this project without technical assistance beyond that which we can provide within the framework of an online forum. In other words, as I so often write in this forum these days, it MAY be that what you need is a consultant… and not merely an answer to a forum post. After all, we can’t be experts in everything.

Peter
OSR
@OSRDrivers

Hi Peter

Possibility 2 makes sense and we have asked the BIOS team to make the necessary changes . Possibility 1 is not possible bcz when i checked the property page of EC driver , it showed “inf name -> machine.inf and inf section -> NO_DRV”
Possibility 3 -> the parent driver is LPC bus driver and i dont have much idea on how to load on it .

So finally sticking to Possibility 2 .

Thank you very much for your time and clarification .

Sorry, but that’s not the correct conclusion. MSFT is not loading a driver for the EC because it doesn’t need one. Your EC does need one (or a sub-device of the EC needs one)… so you COULD therefore load a driver for the EC.

I’m not saying this is the *best* alternative. I’m merely saying, technically, it is *an* alternative. It is also not clear if this would have WHCK consequences.

I agree that Possibility 2 is the “cleanest” approach. It makes clear the relationship of your driver to the device being controlled, for one thing. And the implementation itself is very straight forward.

Peter
OSR
@OSRDrivers

[quote]
Sorry, but that’s not the correct conclusion. MSFT is not loading a driver for
the EC because it doesn’t need one. Your EC does need one (or a sub-device of
the EC needs one)… so you COULD therefore load a driver for the EC.

[quote]

Hi Peter
As per Tim in his post dated 5thNov ,

""But you cannot replace the EC driver,and you cannot filter the EC driver. It is now internal to ACPI.SYS.
http://www.osronline.com/showthread.cfm?link=150332

It may be that you’ll need to find a Microsoft contact to make this
work. “”

But you have mentioned that i can replace EC driver . now i am puzzled .

Hi Tim and Peter
Finally got the driver working :slight_smile: . Thanks to you all . Sorted out the issue with the BIOS team .

YAY! Congratulations! Glad to hear it.

Peter
OSR
@OSRDrivers