I would like to access what i believe is a system address. basically i want to access a device at fed9 0000 in hex.

Question

Hello, I am trying to write a kernal mode driver for windows 8 platform. Basically I have an amd chipset and have determined that I would like to access a register with a certain offset from what amd labels acpimmioaddr base+offset. I have the offset
and now I believe to have found the base or acpimmioaddr which is fed9 0000 in hex. I have determined I need to write a kernal mode driver to do this. In the driver how would I write and read this address? Also a secondary question how would I export functionality
to either a user mode driver (dll) and ultimately an api?
Notes: I am trying to access memory mapped I/O. 
I believe I have to use hal functions but am not sure if it is hal.dll or sys file. I think I need to map the needed system space to kernal mode virtual memory using MmMapIoSpace(). I believe I have read some wheres that this may have changed in more recent
versions of windows. If anyone can help I appreciate the time very much, thank you.

Answer 1

Thank you for responding. Not sure I understand first part about ACPI device. But basically I'm trying to access a gpio that is memory mapped io that will then have a device attatched to it. My understanding so far is that PnP has to detect the device but
there is no way for it to do that. I am new to windows drivers and so when i realized that installing a driver is in itself comparable to complexity as the driver itself, I decided to try and just install a generic driver that does nothing and has no devices
just to see that I am in fact installing the driver. Then I had planed to learn how to load the driver and have it's driver entry function called that can fill in it's respective members. Eventually I had planed on creating ioctl's that could be accessed by
user mode application and mapping physical memory of mmio address to system address. I thought this would allow it to at least work, then I could go back and try and bring it in line with windows methodology. Also there may already be functions already implemented
by system supplied driver and a filter driver may allow it to be more portable but I had not planned on going into that until after I had got something working specific to my platform.
Now just to go over where I am thus far, I will summarize what I believe to be necessary so far. A driver needs a device. Devices are found via hardware and it's respective drivers, which are then enumerated and pnp is alerted at kernal mode. pnp or io manager
finds the driver and only then loads an installed driver or installs and then loads the driver if not installed already. It seems there is no device specific to a amd fusion controller hub gpio pin. Also there is no way for it to no about devices attatched
with out my driver already loaded. I have started to read about bus drivers. I think a bus driver really doesnt fit PnP in that it is kinda already part of the system and self detection kinda doesnt make sense. So can I or do I have to make my driver a bus
driver? Or does acpi or some low level firmware still have to say "hey im a bus and this is how i work" to the os? I looked at toaster sample code and it has an enum executable that plugs in or ejects devices based on device id's also a toaster seems
pretty unorthodox device so could I create my own kind of device fitting to my purpose and then some how make a user mode application which alerts PnP "logically" instead of by hardware? 
Also I had considered another approach of just using anything to that gets automatically enumerated and using it's device type to call my driver, then my driver does it's things even though they are unrelated to the device detected. I know this isnt how
it's supposed to work and also would temporarily mess up PnP for that device for it's intended purpose, but would it allow me to at least access physical memory mapped io? 
Sorry have been racking my head on this for months now and the whole purpose isnt to implement windows methodology but actually completely unrelated, what was originally important is development of new device and for the past 3 months all's I've worked on
is windows drivers and progress has been little or none it seems.