[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.
- Haiku Activity Report - August 2020
- Rust on Haiku: the Case of the Disappearing Deceased Threads
- GSoC2020 Final Report: Input Preferences
- GSoC 2020 Final Report: Improving and Extending Services Kit
- GSoC 2020 Final Report: XFS File System
- GSoC 2020 Project Update(UFS2): Reading Files
- GSoC 2020 Project Update(UFS2): Reading Symboliclinks
- Manipulating window look & behaviour with 'hey'
- GSoC 2020 Project Update: XFS
- July 2020 Activity Report