| Message ID | 20240911-mikrobus-dt-v1-0-3ded4dc879e7@beagleboard.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add generic overlay for MikroBUS addon boards | expand |
On Wed, Sep 11, 2024 at 07:57:17PM +0530, Ayush Singh wrote: > Hello all, > > This is an attempt to add MikroBUS addon support using the approach > described by Grove connector patch series [0]. > > The patch series tests out 2 addon boards + pwm and GPIO on the MikroBUS > connector. The boards used are GPS3 Click (for UART) [1] and Weather > Click (for I2C) [2]. Additionally, I have tested relative GPIO numbering > using devicetree nexus nodes [3]. > > The patch series does not attempt to do any dynamic discovery for 1-wire > eeprom MikroBUS addon boards, nor does it provide any sysfs entry for > board addition/removal. The connector driver might include them after > the basic support is ironed out, but the existing patches for dynamic > overlays work fine. > > The patch series has been tested on BeaglePlay [4]. > > I will now go over individual parts of the patch series, but for a > better picture of the approach, it would be best to checkout [0] first. > > MikroBUS connector driver > ------------------------- > > Just a stub platform driver for now. Will be extended in the future for > dynamic board discovery using 1-wire eeprom present in some MikroBUS > addon boards. > > While it is a stub driver, disabling it will make the GPIO connector > nexus node unreachable (any driver attempting to use it will enter > differed probing). So it is required. > > MikroBUS connector Devicetree > ------------------------------ > > The connector devicetree defines the MikroBUS GPIO nexus node. This > allows using pin numbering relative to MikroBUS connector pins in the > addon boards overlay. Currently, the patch uses a clockwise numbering: > > 0: PWM > 1: INT > 2: RX > 3: TX > 4: SCL > 5: SDA > 6: MOSI > 7: MISO > 8: SCK > 9: CS > 10: RST > 11: AN > > Additionally, in case PWM pin is not using channel 0, a nexus node for pwm > should also be used and go in the connector devicetree. > > MikroBUS connector symbols overlay > ---------------------------------- > > To make an overlay generic we need a standard name scheme which we > use across base boards. For the connector pins the pinmux phandle > shall be: > > <connector-name>_<pin-name>_mux_<pin-function> > > For the parent provider phandle, we use a similar naming scheme: > > <connector-name>_<pin-name>_<pin-function> > > For GPIO controller, I am using `MIKROBUS_GPIO` name since with nexus > nodes, we do not need to define individual pin gpio controllers. > > The string symbols can be replaced with phandles once [5] is accepted. > That will make connector stacking much simpler. > > MikroBUS addon board overlay > ---------------------------- > > The patch puts the addon board overlays in their own directory. I am > using the following naming scheme for MikroBUS addon boards: > > <vendor>-<product_id>.dtso > > Mikroe [6] lists this for all boards in their website, but I am not sure > if other vendors have a product_id. > > This naming also makes future dynamic discovery easier, since click id > spec [7] contains vendor_id and product_id in the header. > > Usage > ----- > > So what does this all look like? Let's take an example of a BeaglePlay > with one MikroBUS connectors for which we have physically attached a > Wather click module to the first connector. Doing ahead of time > command-line DT overlay application: > > ./fdtoverlay \ > -o output.dtb \ > -i k3-am625-beagleplay.dtb \ > k3-am625-beagleplay-mikrobus-connector0.dtbo mikroe-5761.dtbo > > Open Items > ---------- > > - SPI Support: > Currently SPI dt requires `reg` property to specify the > chipselect to use. This, makes the SPI device overlay dependent on the > SPI controller. Thus for SPI support, we need a way to allow defining > SPI chipselect relative to MikroBUS pins, and not the actual device > controller. > > One possible solution is to introduce something like `named-reg` and > allow selecting the chipselect by string array. But this probably > requires more discussion so I have left out SPI support for now. > > NOTE: pins other than the CS MikroBUS pin can be used as chipselect. > See [8]. > > - Controller symbol duplication > The current symbol scheme has multiple symbols for the same underlying > controller (Eg: MIKROBUS_SCL_MUX_I2C_SCL and MIKROBUS_SDA_MUX_I2C_SDA) > point to the same i2c controller. > > I think both of them will always use the same i2c controller, but > maybe there are some exceptions? So I have left it as it is for this > patch series. The same thing also applies to UART and SPI. > > NOTE: with the use of nexus node for GPIO, the GPIO controller symbol > will be the same for all pins. > > - Nexus node dt-bindings > I am not quite sure how to deal with the nexus node properties > (#gpio-cells, gpio-map, gpio-map-mask, gpio-map-pass-thru) since they > seem to conflict with upstream gpio schema (gpio-controller is a > dependency of #gpio-cells). Please submit a fix to dtschema. Either GH PR or patch to devicetree-spec list. Rob
Hi, Am Mittwoch, 11. September 2024, 16:27:17 CEST schrieb Ayush Singh: > Hello all, > > This is an attempt to add MikroBUS addon support using the approach > described by Grove connector patch series [0]. > > The patch series tests out 2 addon boards + pwm and GPIO on the MikroBUS > connector. The boards used are GPS3 Click (for UART) [1] and Weather > Click (for I2C) [2]. Additionally, I have tested relative GPIO numbering > using devicetree nexus nodes [3]. > > The patch series does not attempt to do any dynamic discovery for 1-wire > eeprom MikroBUS addon boards, nor does it provide any sysfs entry for > board addition/removal. The connector driver might include them after > the basic support is ironed out, but the existing patches for dynamic > overlays work fine. > [sniip] To put it in a more abstract perspective, aren't you "just" defining some kind of connector with a fixed layout of pins and features? It's not really different to Arduino Shields and Raspberry Pi hats, no? Ignoring multi-purpose pins for GPIO or e.g. I2C, this is about matching the plugin module's pins to platform-specific on-board peripherals. Sticking the name to MikroBUS might be misleading, because this is AFAICT just a trademark for a specific connector pin layout. This concept could be applied for any kind of connector, where e.g. the I2C interface is mapped to i2c0 on one platform and to lpi2c5 on a different platform. Best regards, Alexander
On 9/13/24 15:35, Alexander Stein wrote: > Hi, > > Am Mittwoch, 11. September 2024, 16:27:17 CEST schrieb Ayush Singh: >> Hello all, >> >> This is an attempt to add MikroBUS addon support using the approach >> described by Grove connector patch series [0]. >> >> The patch series tests out 2 addon boards + pwm and GPIO on the MikroBUS >> connector. The boards used are GPS3 Click (for UART) [1] and Weather >> Click (for I2C) [2]. Additionally, I have tested relative GPIO numbering >> using devicetree nexus nodes [3]. >> >> The patch series does not attempt to do any dynamic discovery for 1-wire >> eeprom MikroBUS addon boards, nor does it provide any sysfs entry for >> board addition/removal. The connector driver might include them after >> the basic support is ironed out, but the existing patches for dynamic >> overlays work fine. >> [sniip] > To put it in a more abstract perspective, aren't you "just" defining some > kind of connector with a fixed layout of pins and features? > It's not really different to Arduino Shields and Raspberry Pi hats, no? > Ignoring multi-purpose pins for GPIO or e.g. I2C, this is about matching > the plugin module's pins to platform-specific on-board peripherals. > > Sticking the name to MikroBUS might be misleading, because this is AFAICT > just a trademark for a specific connector pin layout. > This concept could be applied for any kind of connector, where e.g. > the I2C interface is mapped to i2c0 on one platform and to lpi2c5 > on a different platform. > > Best regards, > Alexander Yes, the only thing specific to mikroBUS in the patches is the connector symbols. Theoretically, it is supposed to be usable with any connector. MikroBUS is just the connector I am trying to apply the concept to. I think I came across a bit too mikroBUS specific in the patches here, since well that is the connector I am currently trying to support, but as the original patches by Andrew [0] explain, this approach was proposed to work as a generic way to support such connectors, and even do connector stacking. Trying to use it with MikroBUS shows some limitations we have with the current device tree stuff 1. SPI chipselect 2. Nexus nodes need the node to have some kind of existing driver 3. A good place to store the board overlays 4. Stacking needs phandle symbols table support 5. Append property support in devicetree And of course, I might encounter more limitations as I continue to test more boards with it. [0]: https://lore.kernel.org/linux-arm-kernel/20240702164403.29067-1-afd@ti.com/ Ayush Singh
On 9/11/24 22:32, Rob Herring wrote: > On Wed, Sep 11, 2024 at 07:57:17PM +0530, Ayush Singh wrote: >> Hello all, >> >> This is an attempt to add MikroBUS addon support using the approach >> described by Grove connector patch series [0]. >> >> The patch series tests out 2 addon boards + pwm and GPIO on the MikroBUS >> connector. The boards used are GPS3 Click (for UART) [1] and Weather >> Click (for I2C) [2]. Additionally, I have tested relative GPIO numbering >> using devicetree nexus nodes [3]. >> >> The patch series does not attempt to do any dynamic discovery for 1-wire >> eeprom MikroBUS addon boards, nor does it provide any sysfs entry for >> board addition/removal. The connector driver might include them after >> the basic support is ironed out, but the existing patches for dynamic >> overlays work fine. >> >> The patch series has been tested on BeaglePlay [4]. >> >> I will now go over individual parts of the patch series, but for a >> better picture of the approach, it would be best to checkout [0] first. >> >> MikroBUS connector driver >> ------------------------- >> >> Just a stub platform driver for now. Will be extended in the future for >> dynamic board discovery using 1-wire eeprom present in some MikroBUS >> addon boards. >> >> While it is a stub driver, disabling it will make the GPIO connector >> nexus node unreachable (any driver attempting to use it will enter >> differed probing). So it is required. >> >> MikroBUS connector Devicetree >> ------------------------------ >> >> The connector devicetree defines the MikroBUS GPIO nexus node. This >> allows using pin numbering relative to MikroBUS connector pins in the >> addon boards overlay. Currently, the patch uses a clockwise numbering: >> >> 0: PWM >> 1: INT >> 2: RX >> 3: TX >> 4: SCL >> 5: SDA >> 6: MOSI >> 7: MISO >> 8: SCK >> 9: CS >> 10: RST >> 11: AN >> >> Additionally, in case PWM pin is not using channel 0, a nexus node for pwm >> should also be used and go in the connector devicetree. >> >> MikroBUS connector symbols overlay >> ---------------------------------- >> >> To make an overlay generic we need a standard name scheme which we >> use across base boards. For the connector pins the pinmux phandle >> shall be: >> >> <connector-name>_<pin-name>_mux_<pin-function> >> >> For the parent provider phandle, we use a similar naming scheme: >> >> <connector-name>_<pin-name>_<pin-function> >> >> For GPIO controller, I am using `MIKROBUS_GPIO` name since with nexus >> nodes, we do not need to define individual pin gpio controllers. >> >> The string symbols can be replaced with phandles once [5] is accepted. >> That will make connector stacking much simpler. >> >> MikroBUS addon board overlay >> ---------------------------- >> >> The patch puts the addon board overlays in their own directory. I am >> using the following naming scheme for MikroBUS addon boards: >> >> <vendor>-<product_id>.dtso >> >> Mikroe [6] lists this for all boards in their website, but I am not sure >> if other vendors have a product_id. >> >> This naming also makes future dynamic discovery easier, since click id >> spec [7] contains vendor_id and product_id in the header. >> >> Usage >> ----- >> >> So what does this all look like? Let's take an example of a BeaglePlay >> with one MikroBUS connectors for which we have physically attached a >> Wather click module to the first connector. Doing ahead of time >> command-line DT overlay application: >> >> ./fdtoverlay \ >> -o output.dtb \ >> -i k3-am625-beagleplay.dtb \ >> k3-am625-beagleplay-mikrobus-connector0.dtbo mikroe-5761.dtbo >> >> Open Items >> ---------- >> >> - SPI Support: >> Currently SPI dt requires `reg` property to specify the >> chipselect to use. This, makes the SPI device overlay dependent on the >> SPI controller. Thus for SPI support, we need a way to allow defining >> SPI chipselect relative to MikroBUS pins, and not the actual device >> controller. >> >> One possible solution is to introduce something like `named-reg` and >> allow selecting the chipselect by string array. But this probably >> requires more discussion so I have left out SPI support for now. >> >> NOTE: pins other than the CS MikroBUS pin can be used as chipselect. >> See [8]. >> >> - Controller symbol duplication >> The current symbol scheme has multiple symbols for the same underlying >> controller (Eg: MIKROBUS_SCL_MUX_I2C_SCL and MIKROBUS_SDA_MUX_I2C_SDA) >> point to the same i2c controller. >> >> I think both of them will always use the same i2c controller, but >> maybe there are some exceptions? So I have left it as it is for this >> patch series. The same thing also applies to UART and SPI. >> >> NOTE: with the use of nexus node for GPIO, the GPIO controller symbol >> will be the same for all pins. >> >> - Nexus node dt-bindings >> I am not quite sure how to deal with the nexus node properties >> (#gpio-cells, gpio-map, gpio-map-mask, gpio-map-pass-thru) since they >> seem to conflict with upstream gpio schema (gpio-controller is a >> dependency of #gpio-cells). > Please submit a fix to dtschema. Either GH PR or patch to > devicetree-spec list. > > Rob I have created a GH PR [0]. [0]: https://github.com/devicetree-org/dt-schema/pull/143 Ayush Singh
Hello all, This is an attempt to add MikroBUS addon support using the approach described by Grove connector patch series [0]. The patch series tests out 2 addon boards + pwm and GPIO on the MikroBUS connector. The boards used are GPS3 Click (for UART) [1] and Weather Click (for I2C) [2]. Additionally, I have tested relative GPIO numbering using devicetree nexus nodes [3]. The patch series does not attempt to do any dynamic discovery for 1-wire eeprom MikroBUS addon boards, nor does it provide any sysfs entry for board addition/removal. The connector driver might include them after the basic support is ironed out, but the existing patches for dynamic overlays work fine. The patch series has been tested on BeaglePlay [4]. I will now go over individual parts of the patch series, but for a better picture of the approach, it would be best to checkout [0] first. MikroBUS connector driver ------------------------- Just a stub platform driver for now. Will be extended in the future for dynamic board discovery using 1-wire eeprom present in some MikroBUS addon boards. While it is a stub driver, disabling it will make the GPIO connector nexus node unreachable (any driver attempting to use it will enter differed probing). So it is required. MikroBUS connector Devicetree ------------------------------ The connector devicetree defines the MikroBUS GPIO nexus node. This allows using pin numbering relative to MikroBUS connector pins in the addon boards overlay. Currently, the patch uses a clockwise numbering: 0: PWM 1: INT 2: RX 3: TX 4: SCL 5: SDA 6: MOSI 7: MISO 8: SCK 9: CS 10: RST 11: AN Additionally, in case PWM pin is not using channel 0, a nexus node for pwm should also be used and go in the connector devicetree. MikroBUS connector symbols overlay ---------------------------------- To make an overlay generic we need a standard name scheme which we use across base boards. For the connector pins the pinmux phandle shall be: <connector-name>_<pin-name>_mux_<pin-function> For the parent provider phandle, we use a similar naming scheme: <connector-name>_<pin-name>_<pin-function> For GPIO controller, I am using `MIKROBUS_GPIO` name since with nexus nodes, we do not need to define individual pin gpio controllers. The string symbols can be replaced with phandles once [5] is accepted. That will make connector stacking much simpler. MikroBUS addon board overlay ---------------------------- The patch puts the addon board overlays in their own directory. I am using the following naming scheme for MikroBUS addon boards: <vendor>-<product_id>.dtso Mikroe [6] lists this for all boards in their website, but I am not sure if other vendors have a product_id. This naming also makes future dynamic discovery easier, since click id spec [7] contains vendor_id and product_id in the header. Usage ----- So what does this all look like? Let's take an example of a BeaglePlay with one MikroBUS connectors for which we have physically attached a Wather click module to the first connector. Doing ahead of time command-line DT overlay application: ./fdtoverlay \ -o output.dtb \ -i k3-am625-beagleplay.dtb \ k3-am625-beagleplay-mikrobus-connector0.dtbo mikroe-5761.dtbo Open Items ---------- - SPI Support: Currently SPI dt requires `reg` property to specify the chipselect to use. This, makes the SPI device overlay dependent on the SPI controller. Thus for SPI support, we need a way to allow defining SPI chipselect relative to MikroBUS pins, and not the actual device controller. One possible solution is to introduce something like `named-reg` and allow selecting the chipselect by string array. But this probably requires more discussion so I have left out SPI support for now. NOTE: pins other than the CS MikroBUS pin can be used as chipselect. See [8]. - Controller symbol duplication The current symbol scheme has multiple symbols for the same underlying controller (Eg: MIKROBUS_SCL_MUX_I2C_SCL and MIKROBUS_SDA_MUX_I2C_SDA) point to the same i2c controller. I think both of them will always use the same i2c controller, but maybe there are some exceptions? So I have left it as it is for this patch series. The same thing also applies to UART and SPI. NOTE: with the use of nexus node for GPIO, the GPIO controller symbol will be the same for all pins. - Nexus node dt-bindings I am not quite sure how to deal with the nexus node properties (#gpio-cells, gpio-map, gpio-map-mask, gpio-map-pass-thru) since they seem to conflict with upstream gpio schema (gpio-controller is a dependency of #gpio-cells). [0]: https://lore.kernel.org/linux-arm-kernel/20240702164403.29067-1-afd@ti.com/ [1]: https://www.mikroe.com/gps-3-click [2]: https://www.mikroe.com/weather-click [3]: https://devicetree-specification.readthedocs.io/en/v0.3/devicetree-basics.html#nexus-nodes-and-specifier-mapping [4]: https://www.beagleboard.org/boards/beagleplay [5]: https://lore.kernel.org/r/20240902-symbol-phandle-v1-0-683efb2a944b@beagleboard.org [6]: https://www.mikroe.com/ [7]: https://github.com/MikroElektronika/click_id [8]: https://www.mikroe.com/spi-extend-click Signed-off-by: Ayush Singh <ayush@beagleboard.org> --- Ayush Singh (7): dt-bindings: connector: Add MikorBUS connector mikrobus: Add mikrobus driver dts: ti: k3-am625-beagleplay: Enable mikroBUS connector dts: ti: beagleplay: Add mikrobus connector symbols addon_boards: Add addon_boards plumbing addon_boards: mikrobus: Add Weather Click addon_boards: mikrobus: Add GPS3 Click Fabien Parent (1): rust: kernel: Add Platform device and driver abstractions .../bindings/connector/mikrobus-connector.yaml | 40 +++ Kbuild | 1 + Kconfig | 2 + MAINTAINERS | 8 + addon_boards/Kconfig | 16 + addon_boards/Makefile | 3 + addon_boards/mikrobus/Makefile | 4 + addon_boards/mikrobus/mikroe-1714.dtso | 28 ++ addon_boards/mikrobus/mikroe-5761-i2c.dtso | 28 ++ arch/arm64/boot/dts/ti/Makefile | 1 + .../k3-am625-beagleplay-mikrobus-connector0.dtso | 49 +++ arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts | 53 ++- drivers/misc/Kconfig | 17 + drivers/misc/Makefile | 1 + drivers/misc/mikrobus.rs | 32 ++ rust/bindings/bindings_helper.h | 1 + rust/kernel/lib.rs | 1 + rust/kernel/platform.rs | 380 +++++++++++++++++++++ 18 files changed, 659 insertions(+), 6 deletions(-) --- base-commit: 9aaeb87ce1e966169a57f53a02ba05b30880ffb8 change-id: 20240826-mikrobus-dt-52eaaadd0b1f Best regards,