From: Vaishnav Achath <vaishnav.a@ti.com> To: Andrew Lunn <andrew@lunn.ch> Cc: Ayush Singh <ayushdevel1325@gmail.com>, Michael Walle <mwalle@kernel.org>, open list <linux-kernel@vger.kernel.org>, <jkridner@beagleboard.org>, <robertcnelson@beagleboard.org>, <lorforlinux@beagleboard.org>, Rob Herring <robh@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>, Tero Kristo <kristo@kernel.org>, Derek Kiernan <derek.kiernan@amd.com>, Dragan Cvetic <dragan.cvetic@amd.com>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Mark Brown <broonie@kernel.org>, Johan Hovold <johan@kernel.org>, Alex Elder <elder@kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, "moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, "open list:SPI SUBSYSTEM" <linux-spi@vger.kernel.org>, "moderated list:GREYBUS SUBSYSTEM" <greybus-dev@lists.linaro.org>, Vaishnav M A <vaishnav@beagleboard.org> Subject: Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector Date: Thu, 21 Mar 2024 12:37:39 +0530 [thread overview] Message-ID: <ded6c350-4c70-4a26-8b18-6605dcc6e084@ti.com> (raw) In-Reply-To: <4c299d42-84c7-46fc-952f-292cef1bb4b4@lunn.ch> Hi Andrew, On 20/03/24 00:53, Andrew Lunn wrote: > On Tue, Mar 19, 2024 at 11:05:37PM +0530, Vaishnav Achath wrote: >> Hi Andrew, >> >> On 19/03/24 17:55, Andrew Lunn wrote: >>>> The device tree defines the SPI controller associated with mikroBUS SPI >>>> pins. The driver on match queries and takes a reference to the SPI >>>> controller but does nothing with it. Once a mikroBUS add-on board is >>>> detected (by passing manifest using sysfs or reading from 1-wire EEPROM), >>>> the driver parses the manifest, and if it detects an SPI device in manifest, >>>> it registers SPI device along with setting properties such as `chip_select`, >>>> `max_speed_hz`, `mode`, etc., >>> >>> How complex can the description of the hardware be in the manifest? >>> >>> Could i describe an SPI to I2C converter? And then a few temperature >>> sensors, a fan controller, and a GPIO controller on that I2C bus? And >>> the GPIO controller is then used for LEDs and a push button? DT >>> overlays could describe that. Can the manifest? >> >> No, it cannot describe such complex hardware, it can only describe simple >> devices (sensors/displays .etc) on a standard mikroBUS add-on board, we did >> a analysis on what mikroBUS add-on boards have driver support in Linux and >> then noticed that most devices does not need this kind of complex >> description to work: >> https://elinux.org/MikroEClicks_with_Linux_Support > > Is that because the current software support is too limited? Are there > manufactures who want to create more complex designed, but are limited > by what can be described in the manifest? > most mikroBUS add-on boards in production lies in the category of sensors, displays, connectivity, mixed signal (ADC/DAC .etc) and if you look at the existing bindings under bindings/iio/ , most devices need only simple descriptions and the properties are mainly standard bus properties (SPI/I2C properties), IRQ, named-gpios, named properties, regulators, clocks the extension to manifest was made taking this into account and the named property description interface just maps the manifest entries to the unified device property interface under include/linux/property.h > Do you have a list of boards without Linux support? Why do they not > have Linux support? Is there a "vendor crap" driver which makes them > work? Does it make them work by working around the manifest > limitations? > I did the survey in 2020, close to 600 board did not have Linux support and 150 board had support then, the boards which did not have Linux support was mostly because there was no corresponding driver present and a lot of these were similar to the 150 that had support (IIO sensors, ADC, DACs .etc), there is no vendor(Example MikroElektronika) drivers being maintained, so I am not sure if there are drivers working around limitations of manifests , but for the 150 boards that we have tested support we never had to make any changes to the underlying device drivers to be supported. >> The greybus manifest already is being used in the greybus susbystem for >> describing an interface and there are already greybus controllers (SPI/I2C >> .etc) being created according to the manifest contents, all this driver does >> is to extend that format to be able to instantiate devices on these buses. > > I don't know anything about greybus, so let me ask a few background > questions. Are these SPI and I2C controller plain Linux SPI and I2C > controllers? They fit the usual device model, they appear in > /sys/class/bus etc? Are the GPIO controllers also just plain Linux > GPIO controllers? All the drivers have a bottom interface which uses > greybus to perform some sort of RPC, but the top interface is standard > Linux. So in fact they are not so different to I2C over USB, SPI over > USB, GPIO over USB? They are very similar and all the details you mentioned are correct, I will provide some comments on the DT proposal you made and why we could not implement that approach initially, primarily it is because PCIe and USB has OF device tree support and USB interface nodes are children of USB device nodes and there is some hardware parent we can tie USB interface to and share/derive the of_node, but in case of greybus we could not find such mapping - looking at your proposal that is more maintainable in the long term, have some doubts regarding the proposal will post in the other thread. Thanks and Regards, Vaishnav > > Andrew
WARNING: multiple messages have this Message-ID (diff)
From: Vaishnav Achath <vaishnav.a@ti.com> To: Andrew Lunn <andrew@lunn.ch> Cc: Ayush Singh <ayushdevel1325@gmail.com>, Michael Walle <mwalle@kernel.org>, open list <linux-kernel@vger.kernel.org>, <jkridner@beagleboard.org>, <robertcnelson@beagleboard.org>, <lorforlinux@beagleboard.org>, Rob Herring <robh@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>, Tero Kristo <kristo@kernel.org>, Derek Kiernan <derek.kiernan@amd.com>, Dragan Cvetic <dragan.cvetic@amd.com>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Mark Brown <broonie@kernel.org>, Johan Hovold <johan@kernel.org>, Alex Elder <elder@kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, "moderated list:ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, "open list:SPI SUBSYSTEM" <linux-spi@vger.kernel.org>, "moderated list:GREYBUS SUBSYSTEM" <greybus-dev@lists.linaro.org>, Vaishnav M A <vaishnav@beagleboard.org> Subject: Re: [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector Date: Thu, 21 Mar 2024 12:37:39 +0530 [thread overview] Message-ID: <ded6c350-4c70-4a26-8b18-6605dcc6e084@ti.com> (raw) In-Reply-To: <4c299d42-84c7-46fc-952f-292cef1bb4b4@lunn.ch> Hi Andrew, On 20/03/24 00:53, Andrew Lunn wrote: > On Tue, Mar 19, 2024 at 11:05:37PM +0530, Vaishnav Achath wrote: >> Hi Andrew, >> >> On 19/03/24 17:55, Andrew Lunn wrote: >>>> The device tree defines the SPI controller associated with mikroBUS SPI >>>> pins. The driver on match queries and takes a reference to the SPI >>>> controller but does nothing with it. Once a mikroBUS add-on board is >>>> detected (by passing manifest using sysfs or reading from 1-wire EEPROM), >>>> the driver parses the manifest, and if it detects an SPI device in manifest, >>>> it registers SPI device along with setting properties such as `chip_select`, >>>> `max_speed_hz`, `mode`, etc., >>> >>> How complex can the description of the hardware be in the manifest? >>> >>> Could i describe an SPI to I2C converter? And then a few temperature >>> sensors, a fan controller, and a GPIO controller on that I2C bus? And >>> the GPIO controller is then used for LEDs and a push button? DT >>> overlays could describe that. Can the manifest? >> >> No, it cannot describe such complex hardware, it can only describe simple >> devices (sensors/displays .etc) on a standard mikroBUS add-on board, we did >> a analysis on what mikroBUS add-on boards have driver support in Linux and >> then noticed that most devices does not need this kind of complex >> description to work: >> https://elinux.org/MikroEClicks_with_Linux_Support > > Is that because the current software support is too limited? Are there > manufactures who want to create more complex designed, but are limited > by what can be described in the manifest? > most mikroBUS add-on boards in production lies in the category of sensors, displays, connectivity, mixed signal (ADC/DAC .etc) and if you look at the existing bindings under bindings/iio/ , most devices need only simple descriptions and the properties are mainly standard bus properties (SPI/I2C properties), IRQ, named-gpios, named properties, regulators, clocks the extension to manifest was made taking this into account and the named property description interface just maps the manifest entries to the unified device property interface under include/linux/property.h > Do you have a list of boards without Linux support? Why do they not > have Linux support? Is there a "vendor crap" driver which makes them > work? Does it make them work by working around the manifest > limitations? > I did the survey in 2020, close to 600 board did not have Linux support and 150 board had support then, the boards which did not have Linux support was mostly because there was no corresponding driver present and a lot of these were similar to the 150 that had support (IIO sensors, ADC, DACs .etc), there is no vendor(Example MikroElektronika) drivers being maintained, so I am not sure if there are drivers working around limitations of manifests , but for the 150 boards that we have tested support we never had to make any changes to the underlying device drivers to be supported. >> The greybus manifest already is being used in the greybus susbystem for >> describing an interface and there are already greybus controllers (SPI/I2C >> .etc) being created according to the manifest contents, all this driver does >> is to extend that format to be able to instantiate devices on these buses. > > I don't know anything about greybus, so let me ask a few background > questions. Are these SPI and I2C controller plain Linux SPI and I2C > controllers? They fit the usual device model, they appear in > /sys/class/bus etc? Are the GPIO controllers also just plain Linux > GPIO controllers? All the drivers have a bottom interface which uses > greybus to perform some sort of RPC, but the top interface is standard > Linux. So in fact they are not so different to I2C over USB, SPI over > USB, GPIO over USB? They are very similar and all the details you mentioned are correct, I will provide some comments on the DT proposal you made and why we could not implement that approach initially, primarily it is because PCIe and USB has OF device tree support and USB interface nodes are children of USB device nodes and there is some hardware parent we can tie USB interface to and share/derive the of_node, but in case of greybus we could not find such mapping - looking at your proposal that is more maintainable in the long term, have some doubts regarding the proposal will post in the other thread. Thanks and Regards, Vaishnav > > Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-21 7:08 UTC|newest] Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-17 19:37 [PATCH v4 0/5] misc: Add mikroBUS driver Ayush Singh 2024-03-17 19:37 ` Ayush Singh 2024-03-17 19:37 ` [PATCH v4 1/5] dt-bindings: misc: Add mikrobus-connector Ayush Singh 2024-03-17 19:37 ` Ayush Singh 2024-03-18 12:22 ` Michael Walle 2024-03-18 12:22 ` Michael Walle 2024-03-18 17:20 ` Ayush Singh 2024-03-18 17:20 ` Ayush Singh 2024-03-19 5:58 ` Krzysztof Kozlowski 2024-03-19 5:58 ` Krzysztof Kozlowski 2024-03-19 7:36 ` Ayush Singh 2024-03-19 7:36 ` Ayush Singh 2024-03-19 9:38 ` Michael Walle 2024-03-19 9:38 ` Michael Walle 2024-03-19 11:36 ` Ayush Singh 2024-03-19 11:36 ` Ayush Singh 2024-03-19 12:08 ` Michael Walle 2024-03-19 12:08 ` Michael Walle 2024-03-19 13:03 ` Ayush Singh 2024-03-19 13:03 ` Ayush Singh 2024-03-19 14:21 ` Michael Walle 2024-03-19 14:21 ` Michael Walle 2024-03-19 17:19 ` Vaishnav Achath 2024-03-19 17:19 ` Vaishnav Achath 2024-03-19 17:35 ` Ayush Singh 2024-03-19 17:35 ` Ayush Singh 2024-03-19 19:32 ` Andrew Lunn 2024-03-19 19:32 ` Andrew Lunn 2024-03-20 16:39 ` Ayush Singh 2024-03-20 16:39 ` Ayush Singh 2024-03-20 18:44 ` Andrew Lunn 2024-03-20 18:44 ` Andrew Lunn 2024-03-21 7:35 ` Vaishnav Achath 2024-03-21 7:35 ` Vaishnav Achath 2024-03-21 12:31 ` Andrew Lunn 2024-03-21 12:31 ` Andrew Lunn 2024-03-19 12:25 ` Andrew Lunn 2024-03-19 12:25 ` Andrew Lunn 2024-03-19 17:35 ` Vaishnav Achath 2024-03-19 17:35 ` Vaishnav Achath 2024-03-19 18:19 ` Conor Dooley 2024-03-19 18:19 ` Conor Dooley 2024-03-21 6:30 ` Vaishnav Achath 2024-03-21 6:30 ` Vaishnav Achath 2024-03-19 19:23 ` Andrew Lunn 2024-03-19 19:23 ` Andrew Lunn 2024-03-21 7:07 ` Vaishnav Achath [this message] 2024-03-21 7:07 ` Vaishnav Achath 2024-03-21 9:38 ` Michael Walle 2024-03-21 9:38 ` Michael Walle 2024-03-21 11:55 ` Vaishnav Achath 2024-03-21 11:55 ` Vaishnav Achath 2024-03-21 12:44 ` Michael Walle 2024-03-21 12:44 ` Michael Walle 2024-03-21 12:55 ` Andrew Lunn 2024-03-21 12:55 ` Andrew Lunn 2024-03-19 6:03 ` Krzysztof Kozlowski 2024-03-19 6:03 ` Krzysztof Kozlowski 2024-03-19 6:42 ` Ayush Singh 2024-03-19 6:42 ` Ayush Singh 2024-03-19 19:37 ` Conor Dooley 2024-03-19 19:37 ` Conor Dooley 2024-03-22 18:15 ` Ayush Singh 2024-03-22 18:15 ` Ayush Singh 2024-03-22 18:51 ` Andrew Lunn 2024-03-22 18:51 ` Andrew Lunn 2024-03-17 19:37 ` [PATCH v4 2/5] spi: Make of_find_spi_controller_by_node() available Ayush Singh 2024-03-17 19:37 ` Ayush Singh 2024-03-19 8:16 ` Markus Elfring 2024-03-19 8:16 ` Markus Elfring 2024-03-17 19:37 ` [PATCH v4 3/5] greybus: Add mikroBUS manifest types Ayush Singh 2024-03-17 19:37 ` Ayush Singh 2024-03-19 8:26 ` Vaishnav Achath 2024-03-19 8:26 ` Vaishnav Achath 2024-03-17 19:37 ` [PATCH v4 4/5] mikrobus: Add mikroBUS driver Ayush Singh 2024-03-17 19:37 ` Ayush Singh 2024-03-17 19:59 ` Randy Dunlap 2024-03-17 19:59 ` Randy Dunlap 2024-03-18 17:34 ` Markus Elfring 2024-03-18 17:34 ` Markus Elfring 2024-03-18 17:58 ` Markus Elfring 2024-03-18 17:58 ` Markus Elfring 2024-03-18 18:41 ` Alex Elder 2024-03-18 18:41 ` Alex Elder 2024-03-18 18:55 ` Greg Kroah-Hartman 2024-03-18 18:55 ` Greg Kroah-Hartman 2024-03-18 18:12 ` Markus Elfring 2024-03-18 18:12 ` Markus Elfring 2024-03-19 6:04 ` Krzysztof Kozlowski 2024-03-19 6:04 ` Krzysztof Kozlowski 2024-03-19 6:47 ` Ayush Singh 2024-03-19 6:47 ` Ayush Singh 2024-03-19 8:00 ` Vaishnav Achath 2024-03-19 8:00 ` Vaishnav Achath 2024-03-20 7:33 ` Krzysztof Kozlowski 2024-03-20 7:33 ` Krzysztof Kozlowski 2024-03-19 8:49 ` Vaishnav Achath 2024-03-19 8:49 ` Vaishnav Achath 2024-03-17 19:37 ` [PATCH v4 5/5] dts: ti: k3-am625-beagleplay: Add mikroBUS Ayush Singh 2024-03-17 19:37 ` Ayush Singh 2024-03-19 5:59 ` Krzysztof Kozlowski 2024-03-19 5:59 ` Krzysztof Kozlowski 2024-03-19 6:34 ` Ayush Singh 2024-03-19 6:34 ` Ayush Singh 2024-03-20 7:31 ` Krzysztof Kozlowski 2024-03-20 7:31 ` Krzysztof Kozlowski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ded6c350-4c70-4a26-8b18-6605dcc6e084@ti.com \ --to=vaishnav.a@ti.com \ --cc=andrew@lunn.ch \ --cc=arnd@arndb.de \ --cc=ayushdevel1325@gmail.com \ --cc=broonie@kernel.org \ --cc=conor+dt@kernel.org \ --cc=derek.kiernan@amd.com \ --cc=devicetree@vger.kernel.org \ --cc=dragan.cvetic@amd.com \ --cc=elder@kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=greybus-dev@lists.linaro.org \ --cc=jkridner@beagleboard.org \ --cc=johan@kernel.org \ --cc=kristo@kernel.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-spi@vger.kernel.org \ --cc=lorforlinux@beagleboard.org \ --cc=mwalle@kernel.org \ --cc=nm@ti.com \ --cc=robertcnelson@beagleboard.org \ --cc=robh@kernel.org \ --cc=vaishnav@beagleboard.org \ --cc=vigneshr@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.