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