Phases

Jump to: navigation, search

Could you please clarify if my understanding of the approach is in the right direction?

mikroBUS bus driver with gbsim[edit]

Modify Greybus to include Mikrobus under GB Bridged Phy similar to other PHY bus like I2C,SPI . So when a manifest under this category is loaded, then all the greybus interfaces(virtual interfaces for each perpiheral on the mikroBUS: I2C,SPI,GPIO,...) are created and then the corresponding new_device(or similar) call in the mikrobus bus driver is made with the platform data for the device fetched from the manifest to instantiate the device on the bus(greybus created mikrobus), the bus driver then completes the platform data structure for the device and call the device driver to instantiate the device on the bus(virtual greybus). gbsim takes care of the transport(greybus mikrobus<->physical mikrobus).

mikroBUS bus driver with I2C EEPROM holding manifest[edit]

In this case, the Mikrobus Bus Driver should fetch the manifest blob from an I2C EEPROM(similar to approach done by Bone Cape Manager) and then pass it to greybus(?), so the greybus mikrobus creation and device instantiation happens in the previous manner itself.

Use the Greybus code to parse the manifest, but do not require gbsim to get the data.

In this case who performs the transport?

09:25, 7 April 2020

mikroBUS bus driver with gbsim[edit]

Adding mikroBUS to the Greybus bridged phys might be the right answer, but I'm not sure. Sounds right.

It seems if we make mikroBUS a bus driver, it should have a 'match' function? https://www.kernel.org/doc/html/latest/driver-api/driver-model/bus.html

Is 'match' not needed in this case? Could their be a 'match' function that ends up calling the 'match' function for the I2C/SPI/UART busses? How would it determine which buses it needs?

Why would the device tree define the transport? So many confusing terms!!!

mikroBUS bus driver with I2C EEPROM holding manifest[edit]

The transport is the physical I2C/SPI/UART busses! The goal is to first get mikroBUS add-on boards working on PocketBeagle+TechLab before worrying about any other transports or other board configurations. By keeping the handling of defining the extra platform data in the mikroBUS bus driver, it should be able to have all the extra definitions it needs right there.

The use of gbsim in the earlier phase was just to try to avoid needing to parse manifest data.

Aside[edit]

I wonder if it would help if I did a device tree example for instantiating a mikroBUS bus. What do you think? I might add that to the main page as a draft.

13:38, 7 April 2020

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:BeagleBoard/Mikrobus Support/Phases/reply (3).