Hi Peter,
Thanks for the detailed and quick explanation. Really appreciate that I have few more doubts.
Because of your specific use case, you simply would write an ordinary PCI device driver that controls your I2C controller at the bottom edge, and that takes whatever Reads, Writes, and a Ioctls that you wish to define from your user app at the top edge.
There is another use case to the one I mentioned in my description. There could be a need wherein, instead of the application directly sending command to the controller to control the peripheral beneath, there could be a KMDF or UMDF peripheral driver present for that peripheral device in the OS. So in this case, the application will not directly talk to controller driver. but talks to the peripheral driver.
This could be achieved using the SPB framework if we are static and using the ACPI table to define the devices and the connections. But unfortunately we are not.
Is there anyway to use the SPB framework and escape from using the ACPI table for Controller and peripheral binding? From the documentation I could see that, there are too much dependencies on the ACPI table. For example, to get the target connection settings, the controller driver needs to call SpbTargetGetConnectionParameters. This API is inturn reading through the ACPI table to obtain the device’s settings.
I am thinking if I can somehow achieve the I2C/SPI controller to device binding without ACPI and through some other means, I can reuse the SPB framework and achieve both the use cases.
IS there a way out here??
Thanks,
Ganesh