@“Peter_Viscarola_(OSR)” said:
But he still has two SPIs in one PCIe function
That’s not clear. Nothing the OP writes is definitively clear, at least to me.
@craig_howard: The OPs requirements seem to have evolved very dramatically since his initial post. Last we heard, he now had a multifunction PCIe endpoint that was permanently attached to the main board that provided one SPI, one I2C, one UART and one GPIO controller. Or, that’s what I understand at least. I can’t exactly envision what that would look like, or how it would get permanently attached, but perhaps that’s from my lack of experience as a system builder.
Sorry for not being clear. I think I dint have the clarity when I first started this thread. But right now I have more clarity on what is needed. Let me list it down by answering @craig_howard’s questionnaire
a) what is the target hardware (commercial off the shelf, like a laptop) or customizable (you’ll order something from Wistron or WiPro)
Ours is a PCIe switch that’s going to be plugged into embedded board like imx.8 which has PCIe slot (M.2 I think). So most likely Windows IoT could be flavor. It has one PCIe Downstream Port and one PCIe multifunction endpoint which has 4 separate functions (4 separate config space for each function).
DS Port 0 : PCIe DS port
DS Port 1: 4 Functions
Function 1: one UART
Function 2: one I2C controller
Function 3: two SPI controllers
Function 4: GPIO controller.
b) what exactly are you trying to accomplish … you’ve mentioned a lot of things here: on the I2C network are you trying to be a master, a slave or a monitor? Same on SPI; master, slave or monitor? GPIO are you trying to read from a GPIO expander (which would mean I2C) or are you really going to have some wires that you can toggle? For UART is this RS232, RS485 or something else and are you going to be a master, a slave or a monitor?
I2C → Master controller
SPI → Master controller
UART → I guess its RS485
GPIO → Generic GPIO controller that exposes around 60 GPIOs.
c) what is the end user going to be … is this targeted for a system integrator (who will likely want to interact with this at the device level) or at a user level (something similar to ReadWriteEverything, or the SIV64 display?
There are 2 use cases:
- There can be other kernel peripheral drivers that can use our Master Controllers to control their peripherals. example: connecting a I2C temperature sensor or a SPI based LCD display.
- There will be no kernel peripheral drivers. The user space application will directly send commands to our controller drivers to control anything that is connected. Example : Connecting a I2C eeprom and sending commands from user space to program that EEPROM. We know that native SPBCx doesn’t allow that but we came across this below link that helps us achieve this.
https://docs.microsoft.com/en-us/windows/uwp/devices-sensors/enable-usermode-access
d) what is the timeframe that you’re looking at, hours/ days/ weeks/ months?
May be next 3 months
Generally, I have found that letting a PC be a PC, Windows be Windows and keeping everything at arms length works best. You’ve got several technologies here (I2C, SPI and GPIO) which really aren’t found on regular hardware and you’re asking Windows to do some things that it’s really not designed to do (such as directly accessing hardware) … that all spells trouble, especially when a new version of Windows comes out every six months and you get to retest everything
I dont have an answer for this.
Question 1:
W.r.t I2C, UART, GPIO controllers we are not using the Mf.sys for the multifunction devices even though we are compliant at this level to PCI multi-function standard. I don’t see any advantage of using Mf.sys for the UART,I2C, SPI, GPIO controllers. What’s the need to use Mf.sys at this level? Can’t we live without that?
Question 2:
With respect to the I2C, UART, GPIO controllers I dont have any issues since these are one instance and I can register them as normal drivers.
So the trouble I have here is with the SPI controller. Since there are 2 SPI controllers on a single config space, I am finding it difficult to enable these 2 SPI controllers upon a single EvtDriverDeviceAdd callback.
For this,
Suggestion from Peter was to write a bus driver on top this SPI controller and enumerate each of the SPI controller.
Suggestion from Pavel was to use the mf.sys and use Varying resource map as mentioned in
https://docs.microsoft.com/en-us/windows-hardware/drivers/multifunction/creating-varying-resource-maps
With this description in mind, is there a clear pointer for me?
Is there anymore ambiguity? I can explain specific things better if needed.
Thanks,
Ganesh.