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 _______________________________________________ greybus-dev mailing list greybus-dev@xxxxxxxxxxxxxxxx https://lists.linaro.org/mailman/listinfo/greybus-dev
|