BeagleBoard/Mikrobus Support

=Improving Linux Support for mikroBUS =

mikroBUS is a standard specification by MikroElektronika that can be freely used by anyone following the guidelines. This page is used to describe the different approaches for improving the support for Mikroe Clicks through Linux Device Drivers, See this page for more details about the initial discussion. The different approaches are outlined below:-
 * Using Greybus Simulator + modifications in manifest specifications (Entire Platform Data through manifest blobs)
 * Using Greybus Simulator + a mikroBus driver to register the devices with additional platform data
 * Mikrobus Driver, does not use Greybus directly but uses the manifest parsing logic to get the platform data(minimal) required for registering the driver(Mikrobus Port Specifications from Device Tree)

=Using Greybus Simulator + modifications in manifest specifications=

When using the Greybus Simulator for Click Board Support, the flow that happens is defined here. The manifest blob is loaded through the Greybus Simulator and passes the information to the kernel Greybus driver which creates the corresponding virtual interfaces(I2C/SPI/...) within the kernel corresponding to the Manifest blob, Greybus Simulator then takes care of the transfers between the Greybus virtual interface and the physical interface. In this approach, the Mikrobus Port Specifications will be bundled with the Greybus Simulator, this approach works well when the Click device does not require Interrupts/Named GPIOs during registering the driver, but clicks which require interrupts/reset/named-gpios fails if this method is directly used. For providing additional information to the driver the following changes should be made : ``` [property 1] type = string value = mymodule,foo-interrupt-gpio
 * Manifest should act as the source of platform-data in the kernel, so changes should be made under the manifest parser to accept all the data fields defined under linux/of.h, a section of the manifest will look like this:

[property 2] type = u8 value = 11 ```
 * Once the platform data is modified, this platform_data is used to load a dynamic Device Tree Overlay, which provides the entries corresponding to the greybus peripheral(SPI/I2C/INT/GPIO), for this, there must be changes made in the [of driver https://github.com/beagleboard/linux/blob/4.14/drivers/of/address.c] to add an of_bus struct corresponding to greybus, once this is implemented, the device instantiation should happen with the corresponding platform data.

This approach is mainly drafted from previous discussions with cfiedt(Christopher Friedt) and mdp(Matt Porter).

Pros

 * Uses Greybus, thus the possibility of expansion/usage of other transports exists.
 * Once manifest parser is modified all types of platform data can be accommodated(which could have been done via DT previously)

Cons

 * Loading of Dynamic Device Tree
 * Uses Greybus Simulator, which handles the interface(SPI/I2C/..) transfers in the userspace thus the performance/speed is low compared to direct interfacing (noticeable when trying display clicks/continously polling a sensor click).

=Using Greybus Simulator + a mikroBus driver=

Through this approach, the main problem of passing additional platform data is solved by using a separate driver(which does not contain any click/port specific information) which is invoked from the greybus driver with the platform data extracted from the manifest.
 * This approach will also require modifying the manifest parsing logic to include platform data parsing.
 * writing the driver to instantiate the platform_device according to platform_data obtained from the manifest.

This approach is mainly drafted from previous discussions with jkridner(Jason Kridner). In both the above approaches, the device driver only sees the greybus peripheral(SPI/I2C/GPIO/..) and not the physical peripheral thus enabling the full features of Greybus for IoT(eg use a different transport like TCP/IP).

Pros

 * Uses Greybus, thus the possibility of expansion/usage of other transports exists.

Cons

 * Uses Greybus Simulator, which handles the interface(SPI/I2C/..) transfers in the userspace thus the performance/speed is low compared to direct interfacing (noticeable when trying display clicks/continously polling a sensor click).

=Mikrobus Driver + Device Tree=

This approach does not involve the use of greybus directly but uses the greybus manifests for providing the platform data, it is actually a combination of the Greybus manifest parsing logic combined with the working of Bone Cape Manager used in the previous BB kernels, the Cape Manager used to load the data for a cape from the Device Tree whereas this bus driver takes the data from the manifest blob passed via the SysFS interface.The Mikrobus port information for the device is parsed from the Device Tree(this information only account for the port information and does not have any relation with the click information)

Pros

 * Interfacing directly to the physical bus, faster performance(than gbsim)

Cons

 * Cannot leverage any benefits of Greybus

=Additional Information=


 * In all the approaches above, the modifications in the manifest parser/while creating manifests ensure that minimal information(drivername,named gpio) is used and no unnecessary information(like clickname) is bundled into the manifest
 * All the approach implementations will be followed by suitable non-trivial(Clicks with Interrupt/Named GPIO) examples and documentation.