Greybus — Re: Greybus For IoT : Click Board Support on Beaglebone Boards

On Sat, Jul 13, 2019 at 9:18 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

Sorry about this, won't happen again, thanks for the tip.

On Sat, Jul 13, 2019 at 06:03:02PM +0530, Vaishnav MA wrote:
> 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?

Yes, of course it describes these devices, but in a way so that the host
can talk to the device. The specifics as to how the i2c/spi/uart device
talks to the "real" hardware on the device side is up to the
firmware/code in the device. Greybus does not care at all about that,
it is merely a transport layer for data that goes across these types of
hardware busses.

> 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.)

Is Linux running on the "device" side? I don't know what a Clickboard
is, nor how they work at all, sorry. You can look at the firmware that
was written for many greybus devices using NuttX in the github repos if
you want examples of how to handle this on the device side. Perhaps
that is the piece you are missing?

tl;dr: the idea of the project is to bind a kernel driver for an existing I2C/SPI chip to an I2C/SPI greybus device

No on the device side, Linux is not running, Click Boards are simply add-on modules(sensors, OLED displays, transceivers ..) which use SPI, I2C or UART to communicate with the Beaglebone and Kernel Drivers exist for most of them. The idea of the project is to attach these devices to already existing kernel drivers through greybus(so as to provide partial hot-plug support; currently support through Device Tree overlay on Beaglebone require a reboot whenever a new overlay for a new click board is added). For this, I am making use of the Greybus Simulator Project (https://github.com/projectara/gbsim) on the Beaglebone Backend and I am able to add support for some of the I2C and SPI Click Boards with simple SPI/I2C interfaces(no Interrupts or other extra platform data).

For example, for SPI based devices I am passing the Driver name to Greybus(via a modified Greybus Simulator Manifest) through the .modalias property which is being sent to the spi_new_device call in greybus , however, since additional platform_data is not being considered in greybus, support for devices(Click Boards) with Interrupt/Reset or other requirements cannot be implemented in this way. Can you recommend the best way to bind an existing Kernel Driver for an I2C/SPI chip for a Generic SPI/I2C based device(with interrupts and other platform specific data).

quoting a discussion between you and Rob H (source: https://lists.gt.net/linux/kernel/2526400 ),

> There's also things that never got solved. Like how do you describe
> devices on I2C, SPI, UART, etc. behind a greybus device? The plan was
> to use DT overlays, but that was never solved and brings a whole set
> of problems to solve upstream.

That is only an issue if you want to bind a kernel driver for an
existing i2c/spi chip to an i2c/spi greybus device. With the code we
have today, we do it for a specific SPI chip (for firmware download),
but rely on everything to be userspace-only accesses to make it simpler
at this point in time.

When DT overlays get more settled down, yes, I want to revisit this idea
of how to do it for greybus devices, but that's a long-term goal and is
not required at all right now to have a working system and devices.

thanks,

greg k-h

I believe this is what I am trying to achieve, I understand that a custom firmware/userspace program for each device will work through Greybus, but the idea of the project was to bind an existing kernel driver to the device.

thanks,

greg k-h

Thanks a lot for your valuable time,

Vaishnav M A