On Sun, Jul 14, 2019 at 01:13:37AM +0530, Vaishnav MA wrote:
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
Yes, I remember reading about this, hopefully it works out :)
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.
Do you have a pointer to the specs for these?
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).
So what is going to be the "transport" layer for greybus here?
If the beaglebone can see the raw SPI/I2C/UART port, and that is where Linux is running, it's going to be a bit hard to use greybus here.
Unless you have a kernel driver for the clickboard that "knows" the resources present for it and then that is what is used when greybus is used as the transport layer.
But maybe I'm confused as to exactly where these click boards are supposed to be in the system.
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).
gbsim is great for doing greybus development of the host code, but tieing it to the actual device side is a bit tough here as that is what gbsim is emulating.
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 https://github.com/beagleboard/linux/blob/f45281297c419d29df9bedbb9d1eaeb12fd2b93b/drivers/staging/greybus/spilib.c#L475 , however, since additional platform_data https://linuxtv.org/downloads/v4l-dvb-internals/device-drivers/API-struct-spi-board-info.html 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).
Use device tree overlays :)
Sorry, couldn't help it... Anyway, you need to get that information from somewhere, does the device itself not "know" it already and then you can use that somehow?
Specs for the click boards might be best so that I can try to figure this out.
quoting a discussion between you and Rob H (source: https://lists.gt.net/linux/kernel/2526400 ),
That's a long thread...
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.
If you are wanting to achieve DT overlays, great! But I don't think that involves messing with greybus here. But again, I could be confused.
thanks,
greg k-h