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@xxxxxx/
Ayush Singh
