Hi Russell,
I had originally worked on this and will try to provide
some more context which is missing in this series. I am
replying from my TI email as I am active here.
On 16/03/24 02:49, Russell King (Oracle) wrote:
On Sat, Mar 16, 2024 at 02:17:24AM +0530, Ayush Singh wrote:
On 3/16/24 01:02, Russell King (Oracle) wrote:
On Sat, Mar 16, 2024 at 12:19:05AM +0530, Ayush Singh wrote:
diff --git a/drivers/misc/mikrobus/Kconfig b/drivers/misc/mikrobus/Kconfig
new file mode 100644
index 000000000000..f0770006b4fe
--- /dev/null
+++ b/drivers/misc/mikrobus/Kconfig
@@ -0,0 +1,19 @@
+menuconfig MIKROBUS
+ tristate "Module for instantiating devices on mikroBUS ports"
+ depends on GPIOLIB
+ depends on W1
+ depends on W1_MASTER_GPIO
+ help
+ This option enables the mikroBUS driver. mikroBUS is an add-on
+ board socket standard that offers maximum expandability with
+ the smallest number of pins. The mikroBUS driver instantiates
+ devices on a mikroBUS port described by identifying data present
+ in an add-on board resident EEPROM, more details on the mikroBUS
+ driver support and discussion can be found in this eLinux wiki :
+ elinux.org/Mikrobus
I think this is a fallacy. I have boards that support Mikrobus - some of
the SolidRun products do. I have several Mikrobus "click" boards.
This help text seems to imply that Mikrobus click boards include an
EEPROM that identify them, hence you make the support for mikroBUS
depend on it. No, this is not the case - the click boards do not
contain a 1-wire EEPROM.
Please fetch a copy of the official Mikrobus specification which is
available here:
https://download.mikroe.com/documents/standards/mikrobus/mikrobus-standard-specification-v200.pdf
and rather than creating something that is implementation specific but
appears to be generic, create something that is generic with
implementation specific extensions.
I think you mean mikroBUS addon boards? mikroBUS is an open socket and click
boards™ are MikroElektronika’s brand of mikroBUS™ add-on boards.
MikroElektronika _owns_ the standard for mikroBUS, they're the ones
who publish it and it has their logo plastered all over it.
Yes, MikroE owns the standard but they do not prevent anyone from
creating new add-on boards or adding the sockets in commercially
available boards, with the only condition that custom mikroBUS add-on
boards cannot be marketed with the name "click" board.
So I think
all click boards™ do have clickID support, but yes, mikroBUS spec is not the
same as clickID and thus are not mutually dependent.
None of the MikroElektronika "click" boards that I have (and thus
officially produced boards) have any ID EEPROM on them, so your
statement is false. For example, if you look at the "relay click"
board schematic:
https://download.mikroe.com/documents/add-on-boards/click/relay/relay-click-schematic-v100-a.pdf
you will find no EEPROM.
The "relay 3" click board also doesn't:
https://download.mikroe.com/documents/add-on-boards/click/relay-3/relay-3-schematic-v100.pdf
However, the "relay 4" click board does:
https://download.mikroe.com/documents/add-on-boards/click/relay_4_click/Relay_4_Click_v100_Schematic.PDF
Now, ClickID is relatively new. Note that the mikroBUS standard dates
from 2011, with v2 coming out in 2015. A blog post introducing ClickID
was posted in November 2023, just some 5 months ago, so that leaves an
awful lot of click boards out there at the moment which have no EEPROM
on them.
If what you have written assumes that all click boards have this EEPROM
then you are - in my opinion - intolerably constraining the usefulness
of your idea for those of us who have click boards bought over the past
few years, and this will confuse users who have these older boards.
"I've enabled mikroBUS support in the kernel, but my board isn't
recognised" will probably end up being a regular cry from people with
this.
So, I think you need to consider how to support the already vast number
of click boards that do not support ClickID.
The same series actually can support mikroBUS add-on boards without
EEPROM as well, it exposes a sysfs interface similar to i2c new_device,
so all you need to do is to plug-in the add-on board, the pass the
manifest using this interface.
Example :
cat /lib/firmware/mikrobus/AMBIENT-2-CLICK.mnfb >
/sys/bus/mikrobus/devices/mikrobus-0/new_device
Reference:
https://docs.beagleboard.org/latest/boards/beagleplay/demos-and-tutorials/using-mikrobus.html#what-if-my-add-on-doesn-t-have-clickid
I am not sure if passing binary manifest blob using the sysfs interface
is an ideal solution, but the driver can support boards without EEPROM.
Actually the 150+ boards we have validated in the past did not have
EEPROM on all of them :
https://github.com/MikroElektronika/click_id/tree/main/manifests
At the moment, my own personal solution is currently to hack the
platform's DT file for the board I wish to use, creating a new variant
of the platform which configures the SoC so the mikroBUS connector pins
are appropriately configured. It would be good to get away from the need
to do that.
Yes, the pain point with creating device tree overlays for mikroBUS
add-on boards is that you need an almost new overlays for each
permutation of the hardware (150+ add-on boards with driver support in
Linux connected on just BeagleBoard platforms like BeaglePlay[1 port],
PocketBeagle [2 port], mikroBUS cape on BB black[4 ports]) is more than
1000 overlays to maintain, this driver aims to split the platform
aspects of mikroBUS (pinmux, SPI/I2C/GPIO controller .etc) from the
add-on board information, thus requiring one device tree overlay per
port and just a single manifest describing the add-on board.
The reason for choosing greybus manifest for the identifier is that so
far we discussed only about physical mikroBUS ports on the board, but we
can also have mikroBUS ports on a remote microcontroller appearing on
host over greybus and there a device tree overlay solution does not work
as the standard identifier mechanism is greybus manifest, some details
on the remote greybus mikrobus port is available here:
https://docs.beagleboard.org/boards/beagleconnect/technology/index.html
Here is an old video of the concept working:
https://www.youtube.com/watch?v=JKrCRRuCw3c
To summarise, the driver with proper fixes and feedback incorporated can
support mikroBUS Click ID boards(plug and play), existing mikroBUS
add-on boards (with a clean way to pass the manifest to driver, slight
manual intervention compared to click ID boards) and also mikroBUS
add-on board connected to a remote microcontroller appearing over
greybus (not part of the series, but mentioning it so that it is clear
why greybus manifest is chosen as the descriptor format).
Thanks and Regards,
Vaishnav
