View source for Talk:BeagleBoard/Mikrobus Support

From eLinux.org
Jump to: navigation, search

I propose the following phases:

mikroBUS bus driver with gbsim

  • Build a mikroBUS bus driver to load I2C, SPI, and UART device drivers
  • Instantiate the driver on PocketBeagle+TechLab using whatever device tree entries you need to define it. Define the bus, not any of the devices.
  • Use as generic manifests as possible with gbsim. No target specific content should go in the manifest, though a mikroBUS-specific resource could be defined.
  • The bus driver should be called (init/probe?) and be able to complete the platform data structure to call the (init/probe?) on the device driver such that no device tree information is required.
  • It might be necessary to augment Greybus with some mikroBUS-specific information, like it was a bus at the same level as I2C, SPI, etc.

mikroBUS bus driver with I2C EEPROM holding manifest

  • init function fetches a Greybus manifest blob from an I2C EEPROM over the mikroBUS I2C bus.
  • I2C EEPROM would be manually programmed to contain the blob.
  • Use the Greybus code to parse the manifest, but do not require gbsim to get the data.

Flesh out the driver for the remaining mikroBUS interfaces

  • Interfaces: PWM, ADC, etc.
  • Extra configuration information for other device types: displays, etc.

Get everything working over actual Greybus

  • Start with Greybus over UART to CC1352R Launchpad with mikroBUS slots.

Contents

Thread titleRepliesLast modified
Phases319:05, 7 April 2020

I propose the following phases:

mikroBUS bus driver with gbsim[edit]

  • Build a mikroBUS bus driver to load I2C, SPI, and UART device drivers
  • Instantiate the driver on PocketBeagle+TechLab using whatever device tree entries you need to define it. Define the bus, not any of the devices.
  • Use as generic manifests as possible with gbsim. No target specific content should go in the manifest, though a mikroBUS-specific resource could be defined.
  • The bus driver should be called (init/probe?) and be able to complete the platform data structure to call the (init/probe?) on the device driver such that no device tree information is required.
  • It might be necessary to augment Greybus with some mikroBUS-specific information, like it was a bus at the same level as I2C, SPI, etc.

mikroBUS bus driver with I2C EEPROM holding manifest[edit]

  • init function fetches a Greybus manifest blob from an I2C EEPROM over the mikroBUS I2C bus.
  • I2C EEPROM would be manually programmed to contain the blob.
  • Use the Greybus code to parse the manifest, but do not require gbsim to get the data.

Flesh out the driver for the remaining mikroBUS interfaces[edit]

  • Interfaces: PWM, ADC, etc.
  • Extra configuration information for other device types: displays, etc.

Get everything working over actual Greybus[edit]

  • Start with Greybus over UART to CC1352R Launchpad with mikroBUS slots.
21:19, 6 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.

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

mikroBUS bus driver with gbsim[edit]

Is 'match' not needed in this case? Could there 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?

As per my understanding match function is required?Which eventually calls the match function of the individual I2C/SPI/UART buses, I was thinking that the manifest has different Cports in it , so we can structure it like this: say for a click that uses I2C and GPIO resources :

; I2C protocol on CPort 1
[cport-descriptor 1]
bundle = 1
protocol = 0x03
property = ...
; GPIO protocol on CPort 2
[cport-descriptor 2]
bundle = 2
protocol = 0x02
property = ...

The property field under each Cport specifies the Extra Platform Data, is this feasible? In this case we can get the required information from the manifest itself.

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

This was a misunderstanding, I was thinking of the bus driver's relation with greybus, The bus driver has no direct relation with greybus right? It is just an independent bus driver, mainly for handling of defining the extra platform data while instantiating the click devices(works similar to Cape Bus difference being the data will be fetched from manifest blob, reusing the greybus manifest parsing logic), in the later phase this bus can be added to greybus Phy.

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.

This would be really helpful

19:05, 7 April 2020