[GSoC 2018: SDHCI MMC Driver]: Week #4
Hey everyone! here I am with another update. Last time I had concluded-“PCI class is not discoverable to device manager”, it was actally a bit wrong. So korli explained that device manager won’t load a driver which system doesn’t know so in order for device manager to consider sdhci bus device, it has to be added under a condition of the devices of same type. So we added it under “disk”. With that he also committed PoC which came out to be very useful but still I took sometime to really understand it.
So next thing which we intended to do is to register a child device or a node which is our picked up device out of all the device which were there on the PCI bus. Now we have to attach these devices on a mmc bus and then we have to configure interrupts and commands for data transfer(Programmed I/O method).
So there’s is something like a bus and bus manager, I really want to clearify these two things now because in next few weeks we will be working on bus manager and we should avoid confusion of any kind. So till now we told device manager that if a sdhci-pci device is attached to the system then it should load the driver from mentioned path unlike PnP devices. Now we have got the driver loaded also we have filtered out the device. Now we have to initiate a bus(mmc) and attach device to it. This will be the role of a bus, now we need to set up a bus manager in order deal with storage(read, write, data transfer etc). It will mainly deal with the commands and expose some API’s for the user to do the operations and build application on top of it.
For the bus we have init_bus(), unint_bus() and bus_removed() under a global structure(gSDHCIPCIDeviceModule). Before explaining about init_bus() I wanted make you notice of something, “cookie” or “bus_cookie”. It is a opaque pointer, we can’t see through this pointer but we can provide our implementation. This makes the code robust accross different platforms. In this particular case init_bus() will attach some useful data about the device via this cookie.
I have successfully registered the child device and also attached it to the bus(mmc). We thought that it would be better if we could divide our module into two for more clearity:
- device: supports_device(), init_device(), register_device(), register_child_device()
- bus: init_bus(), uninit_bus(), remove_bus(), other functions for interrupts
But it became difficult to manage modules and module_dependencies because these are single entry point for a module(binary). You can have any number of files and have a single binary, you just have to mention those in the Jam file. In my case it would be like
KernelAddon sdhci : sdhci_pci.cpp sdhci_device.cpp ;
Then you just have to do
jam -q sdhci
Also, this will update your binary with kernel
jam update-image kernel sdhci
if you have added this
AddFilesToPackage add-ons kernel busses mmc : sdhci ;
I have been trying to split the module into two but I think setting up interrupts is more important and splitting can be done in parallel.
Thanks to korli, PulkoMandy, phoudoin for helping me. I will be soon be ready with a plan for bus manager after setting up the interrupts and registers etc.
- An Update from the Promotion Team
- Haiku activity report - February 2021
- Haiku Survey February/March 2021
- A Brief Look Inside HPKG
- Icculus Microgrant 2020
- Haiku activity report - January 2021
- Debugging RISCV-64 bootloader in QEMU
- Hello from the Haiku Promotion 'Team'!
- Haiku activity report - November and December 2020
- Haiku Depot and Better Icon Handling