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.
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?.
Thanks and Regards
Vaishnav M A GSoC '19 Student Under Beagleboard.org
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
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
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
On Sat, Jul 13, 2019 at 9:18 PM Greg KH gregkh@linuxfoundation.org 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?
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 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).
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
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
On Tue, Jul 16, 2019 at 3:25 PM Greg KH gregkh@linuxfoundation.org wrote:
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:
[...]
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?
There are about 700 different Click board options.
I'm mentoring Vaishnav in this project. I'll try to restate the goal I'd ideally like to see him achieve.
The interim goal is provide a template for others to follow when adding any of these Click boards to a Linux host where existing Linux drivers would be given sufficient platform data via gbsim to be instantiated over greybus using these embedded buses that otherwise are non-discoverable. This solves a few problems:
1. It allows the drivers to be loaded at runtime, rather than be configured into the boot device tree. Loading driver at boot time can be someone reasonable to expect, but it slows the debugging process requiring a reboot and leaving developers with the possibility of making a system not boot easily. While dynamic overlays are somewhat supported via configfs and I'd love to see that continue to move forward, there seems to be a fair amount of push-back due to the security implications of being able to arbitrarily alter the hardware. By going through greybus, we are limited to extending and existing set of embedded busses rather than doing arbitrary pokes into the kernel. So, this is a potentially better way to load these drivers at runtime.
2. By using the Click header as a proxy for the various embedded buses, there is an opportunity for abstraction of the Linux host. For example, on BeagleBone Black, the mikroBUS Cape[1] provides 4 slots for Click boards to be added. Each of these might utilize a different SPI port, I2C port or GPIO pins. By defining a metadata set for the body of Click boards, we could use our implementation of gbsim (or other solution) to map the ports to board resources. The same abstraction should hold true for non-BeagleBoard.org Linux systems, allowing us to better share metadata with folks developing with, say, a Raspberry Pi. So, this is potentially a better way to collaborate on metadata around these Click boards.
3. While this particular project focuses on building a solution for BeagleBone Black and PocketBeagle users via gbsim, because it uses greybus, other transports could potentially be used, either IP (such as demonstrated by Alexandre Bailon[2][3]) or via a microcontroller interface (such as the BeagleBone PRUs). So, this can grow to be a tested set of metadata for connecting to hundreds of IoT sensor/actuator devices that can now be abstracted regarding how they are wired-up to a system. I plan to talk about this a lot more at Linux Plumbers in September.
[1] https://www.mikroe.com/beaglebone-mikrobus-cape [2] https://www.youtube.com/watch?v=7H50pv-4YXw [3] https://elinux.org/images/c/cb/Using_Greybus_for_IoT.pdf [4] https://www.mikroe.com/mikrobus
So what is going to be the "transport" layer for greybus here?
Today, gbsim will provide the transport, however that works.
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.
Somehow, gbsim has already largely addressed this issue as far as I can tell. New ports are getting instantiated. The trick is providing the extra platform information to deal with things like reset controls or interrupt lines. The mikroBus specification[4] has physical positions for reset and interrupt, but I'm not sure this is flexible enough. We still need to translate that into the board-specific resources and pass those to the kernel somehow as well.
I believe there are two problems here to solve:
1. How do we specify the extra data?
2. For a gbsim implementation, how do we add the translation layer and build the platform data needed by the drivers?
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.
We'd like to extend it for the purpose of rapid-prototyping and it would thus act a as a test harness for connecting greybus to a huge collection of sensors/actuators that could be reused across any transport implemented in the future, as greybus was originally intended.
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/f45281297c419d29df9bedbb9d1eaeb12f...
, however, since additional platform_data <
https://linuxtv.org/downloads/v4l-dvb-internals/device-drivers/API-struct-sp...
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 :)
If they can be applied at runtime, that may be a suitable solution. Translation could happen at the userspace/application layer and the overlays could be applied. Due to the pushbacks on overlays being added to the mainline (at least by my understanding), this would continue to live out-of-tree. I'd like to roadmap a way to eventually bring it all back in. Hopefully, I've explained sufficiently why greybus still has a role in this, even if we do generate some dt overlays on-the-fly.
Regards, Jason -- https://beagleboard.org/about - a 501c3 non-profit educating around open hardware computing
On Wed, Jul 17, 2019 at 11:28 AM Jason Kridner jkridner@beagleboard.org wrote:
On Tue, Jul 16, 2019 at 3:25 PM Greg KH gregkh@linuxfoundation.org
wrote:
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:
I believe there are two problems here to solve:
- How do we specify the extra data?
I get that greybus itself shouldn't embed platform data for all the devices, but I think it only encapsulates the bus transports. Is there a generic place for the IRQ/RESET/etc. interfaces most all sensors need?
Let's take a random SPI-based IIO sensor as an example, bmg160[1].
I think an approach could be to come up with a generic IIO protocol class for greybus, rather than an actual protocol class for each sensor we'd like to use. In this generic IIO protocol class implementation, the extra platform data could be included using commonly named greybus gpio resources.
Alternatively, a generic mikroBus protocol class for greybus could be created, assuming all the resources that bus assumes (GPIO/PWM/SPI/I2C/etc.). Not sure if this is better.
Since Click boards will use a common GPIO for IRQ and the SPI device structure includes the irq entry[2], it would seem this could be done in at least a Click-generic way if not an IIO-generic way over greybus.
Of course, drivers that aren't direct usage of SPI (or other provided buses) interfaces like fbtft_device[3] would still require an additional driver to provide their platform data, so we'd either need to figure out how to bury that under a display class or create another driver to provide platform data for that group of drivers.
Would that be the right track?
- For a gbsim implementation, how do we add the translation layer and
build the platform data needed by the drivers?
If there's no preference here, would defining a JSON format and dataset to provide the information to either the gbsim or microcontroller implementations be something acceptable? YAML? other?
Regards, Jason
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv... [2[ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/incl... [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...
-- https://beagleboard.org/about - a 501c3 non-profit educating around open hardware computing
On Mon, Jul 22, 2019 at 12:43 PM Jason Kridner jkridner@beagleboard.org wrote:
On Wed, Jul 17, 2019 at 11:28 AM Jason Kridner jkridner@beagleboard.org
wrote:
On Tue, Jul 16, 2019 at 3:25 PM Greg KH gregkh@linuxfoundation.org
wrote:
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:
I believe there are two problems here to solve:
Let's just focus on #1.
- How do we specify the extra data?
The *extra* data here is whatever else a driver needs to load. Manifests have the buses needed and name to find the driver, but are missing any association between extra signals, like IRQ or other named GPIOs. We'd like a common way to specify those.
Chris has suggested adding some additional data to the manifests, like
[string-descriptor 2]string = driver-specific-gpio-name=manifest-specific-gpio-name
I've proposed trying to define mikroBus as an extra bundle type and add another driver to try to plug in any missing platform data.
Vaishnav has suggested to me this:
consider an example for an mpu9dof click , this click requires a greybus
i2c bus and a greybus gpio interrupt ,
so the manifest will have a i2c protocol on cport1 and gpio protocol on
cport2 , loading the manifest will set up
the corresponding peripherals (greybus gpio, greybus i2c bus) , also the
manifest will have the click name and
port , which will be passed to the Mikrobus driver for device
instantiation
So, again, putting a bit of extra metadata into the manifest, but here, specifically at the bundle level, but, I feel he's saying something very similar to me regarding having a mikroBus driver pull that data out and call the appropriate driver registration.
Is there something just off in our terminology or understanding of the architecture that is preventing us from finding the obvious answer?
-- https://beagleboard.org/about - a 501c3 non-profit educating around open hardware computing
On Mon, Aug 12, 2019 at 11:23 AM Jason Kridner jkridner@beagleboard.org wrote:
On Mon, Jul 22, 2019 at 12:43 PM Jason Kridner jkridner@beagleboard.org wrote:
On Wed, Jul 17, 2019 at 11:28 AM Jason Kridner jkridner@beagleboard.org wrote:
On Tue, Jul 16, 2019 at 3:25 PM Greg KH gregkh@linuxfoundation.org wrote:
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:
I believe there are two problems here to solve:
Let's just focus on #1.
- How do we specify the extra data?
The *extra* data here is whatever else a driver needs to load. Manifests have the buses needed and name to find the driver, but are missing any association between extra signals, like IRQ or other named GPIOs. We'd like a common way to specify those.
Chris has suggested adding some additional data to the manifests, like
[string-descriptor 2]string = driver-specific-gpio-name=manifest-specific-gpio-name
Hi - I'll chime in here because IRC did not really preserve formatting. Maybe greybus kernel code / manifesto already implements something like this, but I just haven't seen it.
My thoughts were that manifests could be a source of platform_data in the kernel just like devicetree or acpi, accessed through the linux/of.h interface in driver code.
For a contrived example, imagine an sensor "foo", that interrupts the host when temperature gets really hot, the driver depends on DT or something to query the value associated with the "foo,interrupt-source" key. The driver would then make a
of_property_read_string(node, "foo,interrupt-source") => "mymodule,foo-interrupt-gpio" ... gpio_find_device( "mymodule,foo-interrupt-gpio" )
In any case, my suggestion is to do something like the following inside the manifest:
[property 1] type = string value = mymodule,foo-interrupt-gpio
[property 2] type = u8 value = 11
; Sensor protocol on CPort 1 [cport-descriptor 1] bundle = 1 protocol = 0x0e property = foo,interrupt-source, 1
; GPIO protocol on CPort 2 [cport-descriptor 2] bundle = 2 protocol = 0x02 property = mymodule,foo-interrupt-gpio, 2
Care would need to be taken that all of the property types defined in linux/of.h were accounted for.
On Mon, Aug 12, 2019 at 12:47 PM Christopher Friedt chrisfriedt@gmail.com wrote:
On Mon, Aug 12, 2019 at 11:23 AM Jason Kridner jkridner@beagleboard.org wrote:
On Mon, Jul 22, 2019 at 12:43 PM Jason Kridner jkridner@beagleboard.org wrote:
On Wed, Jul 17, 2019 at 11:28 AM Jason Kridner jkridner@beagleboard.org wrote:
On Tue, Jul 16, 2019 at 3:25 PM Greg KH gregkh@linuxfoundation.org wrote:
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:
I believe there are two problems here to solve:
Let's just focus on #1.
- How do we specify the extra data?
The *extra* data here is whatever else a driver needs to load. Manifests have the buses needed and name to find the driver, but are missing any association between extra signals, like IRQ or other named GPIOs. We'd like a common way to specify those.
Chris has suggested adding some additional data to the manifests, like
[string-descriptor 2]string = driver-specific-gpio-name=manifest-specific-gpio-name
Hi - I'll chime in here because IRC did not really preserve formatting. Maybe greybus kernel code / manifesto already implements something like this, but I just haven't seen it.
My thoughts were that manifests could be a source of platform_data in the kernel just like devicetree or acpi, accessed through the linux/of.h interface in driver code.
For a contrived example, imagine an sensor "foo", that interrupts the host when temperature gets really hot, the driver depends on DT or something to query the value associated with the "foo,interrupt-source" key. The driver would then make a
of_property_read_string(node, "foo,interrupt-source") => "mymodule,foo-interrupt-gpio" ... gpio_find_device( "mymodule,foo-interrupt-gpio" )
In any case, my suggestion is to do something like the following inside the manifest:
[property 1] type = string value = mymodule,foo-interrupt-gpio
[property 2] type = u8 value = 11
; Sensor protocol on CPort 1 [cport-descriptor 1] bundle = 1 protocol = 0x0e property = foo,interrupt-source, 1
; GPIO protocol on CPort 2 [cport-descriptor 2] bundle = 2 protocol = 0x02 property = mymodule,foo-interrupt-gpio, 2
Care would need to be taken that all of the property types defined in linux/of.h were accounted for.
This would require a rev to the manifest specification, and also some plumbing in the kernel.
On Mon, Aug 12, 2019 at 12:49 PM Christopher Friedt chrisfriedt@gmail.com wrote:
On Mon, Aug 12, 2019 at 12:47 PM Christopher Friedt chrisfriedt@gmail.com wrote:
[snip]
My thoughts were that manifests could be a source of platform_data in the kernel just like devicetree or acpi, accessed through the linux/of.h interface in driver code.
[snip]
Care would need to be taken that all of the property types defined in linux/of.h were accounted for.
This would require a rev to the manifest specification, and also some plumbing in the kernel.
Assuming we take on this task and our proposed modifications are accepted, would it be sufficient to be able to describe the body of 600 mikroBus-compatible Click boards for which at likely hundreds already have drivers in some same shape without needing to touch all the drivers? I mean, my goal here is to produce a pattern that enables getting such boards supported in the kernel tremendously quicker and easier than touching the existing body of microcontroller firmware.
-- https://beagleboard.org/about - a 501c3 non-profit educating around open hardware computing
On Mon., Aug. 12, 2019, 2:06 p.m. Jason Kridner, jkridner@beagleboard.org wrote:
On Mon, Aug 12, 2019 at 12:49 PM Christopher Friedt chrisfriedt@gmail.com wrote:
On Mon, Aug 12, 2019 at 12:47 PM Christopher Friedt chrisfriedt@gmail.com wrote:
[snip]
My thoughts were that manifests could be a source of platform_data in the kernel just like devicetree or acpi, accessed through the linux/of.h interface in driver code.
[snip]
Care would need to be taken that all of the property types defined in linux/of.h were accounted for.
This would require a rev to the manifest specification, and also some plumbing in the kernel.
Assuming we take on this task and our proposed modifications are accepted, would it be sufficient to be able to describe the body of 600 mikroBus-compatible Click boards for which at likely hundreds already have drivers in some same shape without needing to touch all the drivers? I mean, my goal here is to produce a pattern that enables getting such boards supported in the kernel tremendously quicker and easier than touching the existing body of microcontroller firmware.
Yes. We would essentially just be using the same interface as device tree, so if the drivers used device tree before, they would Just Work™ with this change.
There are some intricacies though. Specifically to ensure that "phandles" referenced resources on the same physical module.
Technically speaking, it *might* be possible to string a wire up from a remote module to the host gpio, or from one module to another module, but I just can't see that as being practical.
On Mon, Aug 12, 2019 at 12:49:59PM -0400, Christopher Friedt wrote:
On Mon, Aug 12, 2019 at 12:47 PM Christopher Friedt chrisfriedt@gmail.com wrote:
On Mon, Aug 12, 2019 at 11:23 AM Jason Kridner jkridner@beagleboard.org wrote:
On Mon, Jul 22, 2019 at 12:43 PM Jason Kridner jkridner@beagleboard.org wrote:
On Wed, Jul 17, 2019 at 11:28 AM Jason Kridner jkridner@beagleboard.org wrote:
On Tue, Jul 16, 2019 at 3:25 PM Greg KH gregkh@linuxfoundation.org wrote:
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:
I believe there are two problems here to solve:
Let's just focus on #1.
- How do we specify the extra data?
The *extra* data here is whatever else a driver needs to load. Manifests have the buses needed and name to find the driver, but are missing any association between extra signals, like IRQ or other named GPIOs. We'd like a common way to specify those.
Chris has suggested adding some additional data to the manifests, like
[string-descriptor 2]string = driver-specific-gpio-name=manifest-specific-gpio-name
Hi - I'll chime in here because IRC did not really preserve formatting. Maybe greybus kernel code / manifesto already implements something like this, but I just haven't seen it.
My thoughts were that manifests could be a source of platform_data in the kernel just like devicetree or acpi, accessed through the linux/of.h interface in driver code.
For a contrived example, imagine an sensor "foo", that interrupts the host when temperature gets really hot, the driver depends on DT or something to query the value associated with the "foo,interrupt-source" key. The driver would then make a
of_property_read_string(node, "foo,interrupt-source") => "mymodule,foo-interrupt-gpio" ... gpio_find_device( "mymodule,foo-interrupt-gpio" )
In any case, my suggestion is to do something like the following inside the manifest:
[property 1] type = string value = mymodule,foo-interrupt-gpio
[property 2] type = u8 value = 11
; Sensor protocol on CPort 1 [cport-descriptor 1] bundle = 1 protocol = 0x0e property = foo,interrupt-source, 1
; GPIO protocol on CPort 2 [cport-descriptor 2] bundle = 2 protocol = 0x02 property = mymodule,foo-interrupt-gpio, 2
Care would need to be taken that all of the property types defined in linux/of.h were accounted for.
This would require a rev to the manifest specification, and also some plumbing in the kernel.
I have no objection to that as long as we can do so in a backwards-compatible way (and I think we can).
thanks,
greg k-h
-
Christopher Friedt -
Greg KH -
Jason Kridner -
Vaishnav MA