Hi Andrew, On 21/03/24 00:14, Andrew Lunn wrote:
On Wed, Mar 20, 2024 at 10:09:05PM +0530, Ayush Singh wrote:On 3/20/24 01:02, Andrew Lunn wrote:Yes, after discussion with Vaishnav and trying to brainstorm some way to do the same thing with dt overlays, it seems that trying to use dt overlays will mean need to have completely separate implementation of mikroBUS for local ports and mikroBUS over greybus.Could you explain why please? Are greybus I2C bus masters different from physical I2C bus masters? Are greybus SPI bus masters different from physical SPI bus masters?Well, they are virtual, so they are not declared in the device tree. I have linked the greybus i2c implementation. It basically allocates an i2c_adpater and then adds it using `i2c_add_adapter` method. This adapter can then be passed to say mikroBUS driver where it can be used as a normal i2c_adapter, and we can register the device to it.Being virtual does not really stop it being added to the DT. I'm making this all up, but i assume it will look something like this: greybus@42 { compatible = "acme,greybus"; reg = <0x42 0x100>; This would represent the greybus host controller. module@0 { reg = <0>; This would represent a module discovered on the bus. I assume there is some sort of addressing? The greybus core code dynamically creates the node in DT to describe the modules it has discovered. This is not too different to USB. You can already describe USB devices in DT, but the assumption is you know they exists, e.g. because they are hard wired, not hot-plugable. The USB core will associate the USB device with the node in DT. But actually creating a node in DT is not too big a jump. interface@0 { compatible = "greybus,i2c"; reg = <0>; } interface@1 { compatible = "greybus,spi"; reg = <1>; } interface@10 { compatible = "greybus,gpio"; reg = <10>; } It can then enumerate the interfaces on the module, and create the I2C node, SPI bus node, the gpio controller etc. Again, the greybus core can add nodes to DT to described the discovered hardware, and associate them to the linux devices which are created.
This proposal looks great and would be the ideal solution, but we met with few challenges when initially trying to implement something like this and had to drop and take the route with minimal development effort to just instantiate mikroBUS devices.
From what we understand, you are recommending to change the manifest description format used by greybus to device tree and also add of_bus support for greybus - now this will not only solve instantiating mikrobus devices on greybus but even complex devices on greybus making it a robust solution and using standard tools and support DT offers.
However we have a few doubts:* For USB or PCIe, to add OF device tree support the parent devices are physically present, for example USB device is a child node of USB controller (physically description available in a SoC DT) and USB interfaces are child of USB devices, how would that hierarchy look for greybus devices?
Would it beUSB/UART/transport controller -> AP Bridge host controller -> Module -> interface -> bundle -> CPort ?
When this mikrobus driver was initially implemented we could not think of such an approach as the SVC and Control functionality were implemented in userspace with gbridge ( https://github.com/anobli/gbridge ) with a netlink interface to kernel greybus, but today there are references to do it completely in kernel ( drivers/greybus/gb-beagleplay.c) and your proposal is implementable.
Also with this the manifesto tool which is not very well maintained is not necessary : https://github.com/projectara/manifesto
That gives you what you need to load a DT overlay to make use of these devices. That overlay would contain one of your virtual mikroBUS controllers. This virtual controller is basically a phandle-proxy. The virtual mikroBUS controllers is a consumer of phandles to an I2C bus, an SPI bus, GPIO bus which makes up the pins routed to the mikroBUS connector. The virtual mikroBUS controllers is also a provider of an I2C bus, an SPI bus, GPIO controller. The mikroBUS device consumes these I2C bus, SPI bus etc. The virtual mikroBUS controllers makes it simpler for the device to find the resources it needs, since they are all in one place. For a physical mikroBUS you have a DT node with phandles to the physical devices. For greybus you create a virtual device with phandles to the virtual devices added to the DT bus. You then have everything you need to describe the mikroBUS devices. For very simple devices you convert the manifest to a DT overlay and load it. For complex devices you directly use a DT overlay. I also don't see any need to do the manifest to DT overlay conversion on the fly. You have a database of manifests. They could be converted to DT and then added to the linux-firmware repo, for example. If device with an unknown manifest is found,
How do we know if we found a device with unknown manifest if we don't read the EEPROM?
it should be possible to
read the manifest in userspace via its eeprom in /sys/class/. An tool could create DT blob and add it to /lib/firmware to get it working locally, and provide suggestions how to contribute it to the linux firmware project?
Agreed, but on what basis will you load the particular manifest for a add-on board if you are not reading the DT overlay (or manifest blob) from the EEPROM?
Thanks and Regards, Vaishnav
Andrew
