Laird Connectivity is now Ezurio/filters:background_color(white)/2024-12/SDC-SSD40NBT.png)
Answer
1) The SD host controller driver (their driver, not ours) detects that a device is on the SDIO bus and signals the SD bus driver (a Microsoft driver) 2) The SD bus driver enumerates the card to determine what device it is and what client driver needs to be loaded. The bus driver does this at a low clock frequency because it doesn?t yet know what bus speed the client device can support. Note that the host controller driver is the one that actually performs all accesses to the card as it is the one that manages the actual SDIO controller hardware on the host platform. The bus driver is accessing the card via the host controller driver. 3) The SD bus driver determines that our driver is the ?client driver? registered for the card by reading the vendor/product IDs from the card and looking up that information in the registry. Our driver is registered for that combination of VID/PID. 4) The bus driver loads the client driver, which in this case is our driver. 5) The client driver continues initialization, which includes accessing the card itself by making calls to the SD bus driver which passes those calls on to the host controller driver which implements the actual card access via the host controller itself in the host CPU. It?s important to note that the client driver (us) only requests that a card access be made; it is the host controller driver that implements the access via the host controller on the host CPU. 6) Very early in the initialization sequence the client driver (us) makes a call to the bus driver to configure the bus speed, bus width etc. The speed is the lower of what the card supports and what the host controller supports on that slot. From that point on, all accesses are occurring at a much higher bus speed. 7) The card continues initialization, which includes downloading the firmware and then enabling interrupts. From this point on, interrupts have to be working for the card to function properly.