Hi,

Thanks a lot for your quick response, the project aims to implement support for the Clickboards(load the corresponding kernel driver for the clickboard with corresponding parameters) through greybus manifests instead of the existing support via Device Tree overlays(which requires a reboot in Beaglebone when loading a new overlay), does greybus currently allow to describe devices on I2C, SPI, UART, etc. behind a greybus device? If not what would be the best way to do it? (going through some of the previous discussions on the maiing list I saw suggestions regarding adding Device Tree Support, if it is feasible could you please elaborate on how it can be implemented so that I can try to do it.)

Thanks and Regards

Vaishnav M A

GSoC '19 Student Under Beagleboard.org

On Sat, Jul 6, 2019 at 2:26 PM Greg KH <gregkh@linuxfoundation.org> wrote:

On Thu, Jul 04, 2019 at 01:16:48AM +0530, Vaishnav MA wrote:
> Hi,
>
> I have been working on the Google Summer of Code Project : Click Board
> Support through Greybus
> <https://summerofcode.withgoogle.com/projects/#5996499987595264> , which
> aims to bring in support for MikroElektronika Click Boards
> <https://www.mikroe.com/click> through Greybus Simulator
> <https://github.com/projectara/gbsim> , I was able to set up and bring in
> support for some of the Click boards through Greybus Simulator and passing
> the properties related to the Click Board device driver manipulating the
> product string and vendor string properties in the manifest, however I am
> stuck now as some of the click boards require additional platform data(like
> Reset Pin, Interrupts..etc) passed to the spi_new_device/i2c_new_device
> calls, does Greybus allow passing of these parameters to the driver, if so
> can someone guide me with the documentation for the same or point me a
> suitable example so that I can implement the solution in the project.

Greybus does support passing some of those options to the device, but I
don't see how reset pin and interrupts matter from the host side of
things here. Why do they need to be passed to the greybus host? Aren't
they specific to the greybus "device" in how it actually turns those
greybus messages into specific commands to the real hardware?

You "know" the interrupt and reset pin and those attributes on the
device, and use that for when you need to talk to the real hardware
device. Greybus is just a transfer layer of a generic SPI/I2C message
to the device itself.

Does that help any?

> If greybus doesn't allow for passing these parameters what would be the
> ideal way to bring in support for these click boards(which mostly uses
> SPI/I2C interfaces) through the greybus subsystem?.

Just create a new greybus device for each board and you should be fine.

thanks,

greg k-h