Add generic overlay for MikroBUS addon boards

[PATCH 0/8] Add generic overlay for MikroBUS addon boards

Posted by Ayush Singh 2 months, 2 weeks ago

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

Best regards,
--
Ayush Singh <ayush@beagleboard.org>

Re: [PATCH 0/8] Add generic overlay for MikroBUS addon boards

Posted by Rob Herring 2 months, 2 weeks ago

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

Re: [PATCH 0/8] Add generic overlay for MikroBUS addon boards

Posted by Ayush Singh 2 months, 1 week ago

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

Re: [PATCH 0/8] Add generic overlay for MikroBUS addon boards

Posted by Alexander Stein 2 months, 2 weeks ago

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
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH 0/8] Add generic overlay for MikroBUS addon boards

Posted by Ayush Singh 2 months, 2 weeks ago

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