Hi All
I need your help in writing a driver which is ACPI based . The requirement is to develop a driver for a hardware which is connected through LPC interface and the communication to the device is using ACPI commands. Is there any sample driver available to start with ?
No sample that I know of, but it’s pretty easy.
Have your driver “claim” the device via the INF file (if the device’s _HID is XXXX, you specify ACPI\XXXX as the name your device claims).
Then you issue IOCTL_ACPI_ calls to do stuff:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff536139(v=vs.85).aspx
And in case you wondered: You definitely want to do this in KMDF.
Peter
OSR
@OSRDrivers
Hi Peter
Thanks for the reply . I don’t have idea on that . Its a requirement to develop a driver for a custom hardware that has multiple interfaces in it . The Custom hardware is connected to the main board using LPC interface and the OS is Windows embedded 7 and the communication to the custom hardware is through ACPI commands. I don’t have any idea on how the OS will enumerate the interfaces in the custom hardware . Can you give inputs on how to start with ??
should I write multiple drivers for different interfaces exposed by the hardware or one driver is enough???
On Sep 21, 2014, at 8:38 AM, xxxxx@gmail.com wrote:
Hi Peter
Thanks for the reply . I don’t have idea on that . Its a requirement to develop a driver for a custom hardware that has multiple interfaces in it . The Custom hardware is connected to the main board using LPC interface and the OS is Windows embedded 7 and the communication to the custom hardware is through ACPI commands. I don’t have any idea on how the OS will enumerate the interfaces in the custom hardware . Can you give inputs on how to start with ??
You have to KNOW this. The operating system has no magic. It?s entirely up to the ACPI BIOS DSDT table. The DSDT will identify devices that need drivers, and the operating system will go find those drivers. So, if you have an ACPI team, you will have to ask them what the drivers are.
should I write multiple drivers for different interfaces exposed by the hardware or one driver is enough???
It depends. If the interfaces are all similar drivers (for example, several serial ports or several I2C ports), then you can handle them with one driver. Otherwise, you probably need multiple drivers, because they?ll each expose different interfaces to the rest of the system.
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim
Thanks for the inputs . I will check with the ACPI team . Will the ACPI based driver will be different from other drivers , like , should special APIs has to be used to register with the ACPI or it is same as other KMDF drivers with usual add_Device , Prepare_hardware etc?
xxxxx@gmail.com wrote:
Thanks for the inputs . I will check with the ACPI team . Will the ACPI based driver will be different from other drivers , like , should special APIs has to be used to register with the ACPI or it is same as other KMDF drivers with usual add_Device , Prepare_hardware etc?
It’s a perfectly normal PnP driver. If the DSDT is set up to assign
resources to you (like I/O ports or mapped memory), they will be handed
to your PrepareHardware callback. But if you need resources that can’t
be described in PrepareHardware, like general purpose events, then you
will have to call into ACPI. You do that by calling
WdfFdoQueryForInterface and asking for GUID_ACPI_INTERFACE_STANDARD,
which gives you an ACPI_INTERFACE_STANDARD structure. You can look that
up in the WDK (in wdm.h) to see the functions you get:
GpeConnectVector
GpeDisconnectVector
GpeEnableEvent
GpeDisableEvent
GpeClearStatus
RegisterForDeviceNotifications
UnregisterForDeviceNotifications
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim/Peter
Finally got inputs from ACPI team . The hardware has _HID entry and
resource list in the DSDT table entry . It also has _GPE entry which has
operationregion mentioned. Can you give some inputs on that and why it is
needed ? .
As I already mentioned . eventhough my hardware is connected to LPC ,
the requirement is to communicate to the hardware using ACPI commands. So
,should I need to include ACPI.sys driver in my inf file ? or to register
with ACPI ??
Is there any API available to register with ACPI ?
On Mon, Sep 22, 2014 at 10:30 PM, Tim Roberts wrote:
> xxxxx@gmail.com wrote:
>
> Thanks for the inputs . I will check with the ACPI team . Will the ACPI based driver will be different from other drivers , like , should special APIs has to be used to register with the ACPI or it is same as other KMDF drivers with usual add_Device , Prepare_hardware etc?
>
>
> It’s a perfectly normal PnP driver. If the DSDT is set up to assign
> resources to you (like I/O ports or mapped memory), they will be handed to
> your PrepareHardware callback. But if you need resources that can’t be
> described in PrepareHardware, like general purpose events, then you will
> have to call into ACPI. You do that by calling WdfFdoQueryForInterface and
> asking for GUID_ACPI_INTERFACE_STANDARD, which gives you an
> ACPI_INTERFACE_STANDARD structure. You can look that up in the WDK (in
> wdm.h) to see the functions you get:
>
> GpeConnectVector
> GpeDisconnectVector
> GpeEnableEvent
> GpeDisableEvent
> GpeClearStatus
> RegisterForDeviceNotifications
> UnregisterForDeviceNotifications
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
On Oct 18, 2014, at 9:54 AM, unknown > wrote:
Hi Tim/Peter
Finally got inputs from ACPI team . The hardware has _HID entry and resource list in the DSDT table entry . It also has _GPE entry which has operationregion mentioned. Can you give some inputs on that and why it is needed ?
_GPE provides a way ACPI to to signal to a driver that some general-purpose I/O line has fired.
As I already mentioned . eventhough my hardware is connected to LPC , the requirement is to communicate to the hardware using ACPI commands. So ,should I need to include ACPI.sys driver in my inf file ? or to register with ACPI ??
Is there any API available to register with ACPI ?
Your driver has to get loaded somehow. If the _GPE is associated with some piece of hardware that doesn?t have a normal driver, then the DSDT will create a hardware ID for it (these are the ones with three letters and four numbers, like ABC0123). Your INF file will claim that hardware ID (ACPI\ABC0123). Your bus driver will be ACPI.
Once you are loaded, you can use the ACPI APIs that I mentioned previously.
–
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.</mailto:xxxxx>
And that will be the hardware ID used to enumerate the device… so, your driver will install on ACPI\<_HID>
Needed by what?
With all due respect, if you’re writing the driver for the device, you are the one that needs to be the expert on (a) the hardware resources available, (b) the functionality required, (c) how to use the available resources to achieve the required functionality.
Nobody on this forum can tell you.
It’s like asking “My device has four 32-bit registers… can you tell me what they’re for?” Well, no. Broadly speaking, they’re for controlling your device, but they could be for anything at all within that realm.
Peter
OSR
@OSRDrivers
Hi Tim
my hardware has id PNP0C09 and it is enumerated as Embedded controller;but when i clicked the driver properties in device manager , it is saying “No driver is needed for the device” . . so loaded my driver on this instance.After loading ther driver there was yellow color exclamation mark on the driver and it asked for restart . when i restarte the system, the yellow mark went .
But i am not able to see the log messages in Debugview and also “Disable” option is not there(after loading the driver) when i right clikced on the driver
I also registered for device notification , but i am not getting any notification from the hardware.
And am not able to find much info regarding
GpeConnectVector
GpeDisconnectVector
GpeEnableEvent
GpeDisableEvent
Is there any document available which explains how to use , for example, GpeEnableEvent ?
xxxxx@gmail.com wrote:
Hi Tim
my hardware has id PNP0C09 and it is enumerated as Embedded controller;but when i clicked the driver properties in device manager , it is saying “No driver is needed for the device” . .
Right, because that identifier is listed in the standard “machine.inf”
as needing no driver.
so loaded my driver on this instance.After loading ther driver there was yellow color exclamation mark on the driver and it asked for restart . when i restarte the system, the yellow mark went .
But i am not able to see the log messages in Debugview and also “Disable” option is not there(after loading the driver) when i right clikced on the driver
Does Device Manager now show your driver as the driver for the device?
Have you selected “Enable Verbose Kernel Output” in DebugView?
And am not able to find much info regarding
GpeConnectVector
GpeDisconnectVector
GpeEnableEvent
GpeDisableEventIs there any document available which explains how to use , for example, GpeEnableEvent ?
No, I never found a document. You’ll have to call an ACPI method (using
IOCTL_ACPI_EVAL_METHOD) to fetch your GPE event number from the DSDT
(which means the DSDT had better have a method to return it). That
event number is the second parameter to all of those APIs.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim
Does Device Manager now show your driver as the driver for the device?
YES
Have you selected “Enable Verbose Kernel Output” in DebugView
YES
I tried loading the same driver on “Battery” instance. in that case i am able to see log messages and it was not asking for restart when i loaded the driver .
xxxxx@gmail.com wrote:
> Does Device Manager now show your driver as the driver for the device?
YES
> Have you selected “Enable Verbose Kernel Output” in DebugView
YESI tried loading the same driver on “Battery” instance. in that case i am able to see log messages and it was not asking for restart when i loaded the driver .
Well, that’s where you want to be, right? PNP0C09 is the generic
identifier for the “ACPI Embedded Controller”. That device used to have
its own driver stack, but as of Vista that device is handled entirely
within ACPI.SYS. You can’t take ownership of it. That’s why it matches
the “no driver” driver.
This document says that a smart battery is supposed to be exposed as
ACPI0002, but I’m a fair ways outside of my comfort zone now:
http://www.acpi.info/acpi_faq.htm
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim
Should i ask the BIOS developer to change the ID for our embedded controller so that Windows doesn’t load the driver for it???
If not , then is there any ways to load my driver for our controller???
And also , my battery has an ID of ACPI\PNP0C0A
xxxxx@gmail.com wrote:
Should i ask the BIOS developer to change the ID for our embedded controller so that Windows doesn’t load the driver for it???
If not , then is there any ways to load my driver for our controller???
The Windows team did not anticipate that anyone would ever need to
replace or extend the Embedded Controller driver. It is simply not a
supported scenario. That component belongs to ACPI.SYS, end of story.
Why do you need your own driver for the EC?
And also , my battery has an ID of ACPI\PNP0C0A
That’s what it should have, for a battery that is controlled through
ACPI methods. That’s matched by battery.inf, which loads CmBatt.sys.
You should be able to replace that, assuming you know what interfaces
you have to provide. I assume the standard battery interfaces are
described in the ACPI spec somewhere.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>Why do you need your own driver for the EC?
the EC has its own custom defined interfaces connected to it. We want to control those interfaces using ACPI commands . So thought of writing our own driver and communicate with EC through ACPI commands. Maybe , i am not correct as i am new to ACPI based driver development.
In this case should i write a filter driver and pass the commands to the interfaces to control them?
xxxxx@gmail.com wrote:
> Why do you need your own driver for the EC?
the EC has its own custom defined interfaces connected to it. We want to control those interfaces using ACPI commands. So thought of writing our own driver and communicate with EC through ACPI commands. Maybe , i am not correct as i am new to ACPI based driver development.
In this case should i write a filter driver and pass the commands to the interfaces to control them?
If you have a device that is a child of the EC (like a battery), you can
expose an identifier for that device that loads a driver, and have that
driver send ACPI method calls. 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. ACPI is an ugly area that makes most driver writers run in horror
in the opposite direction.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
ohhhhhh 
…As u said , all these days i was doing something which should not be done …
Can i pass the IOCTL_ACPI_XXXX ioctls from application to the EC driver(provided by Microsoft) to get my work done??? or can i ask the BIOS team to create a new entry for the interfaces (to be controlled) so that i can load my own driver and pass ACPI commands to get the work done???
xxxxx@gmail.com wrote:
ohhhhhh
Can i pass the IOCTL_ACPI_XXXX ioctls from application to the EC driver(provided by Microsoft) to get my work done??? or can i ask the BIOS team to create a new entry for the interfaces (to be controlled) so that i can load my own driver and pass ACPI commands to get the work done???
What kind of work are you doing? You can call those ioctls from user
mode, but they have to be going to an ACPI-created PDO. That usually
means you have to have a driver as a child device of ACPI.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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