On Mon, Mar 18, 2024 at 01:07:09AM +0530, Ayush Singh wrote:
Add DT bindings for mikroBUS interface. MikroBUS is an open standard developed by MikroElektronika for connecting add-on boards to microcontrollers or microprocessors.
mikroBUS is a connector and does not have a controller. Instead the software is responsible for identification of board and setting up / registering uart, spi, i2c, pwm and other buses. Thus it needs a way to get uart, spi, i2c, pwm and gpio controllers / adapters.
A mikroBUS addon board is free to leave some of the pins unused which are marked as NC or Not Connected.
But your binding makes everything required. Why would I need to instantiate and connect an i2c controller to the mikroebus header if I don't intend connecting any mikroebus devices that need one?
Some of the pins might need to be configured as GPIOs deviating from their reserved purposes Eg: SHT15 Click where the SCL and SDA Pins need to be configured as GPIOs for the driver (drivers/hwmon/sht15.c) to work.
For some add-on boards the driver may not take care of some additional signals like reset/wake-up/other. Eg: ENC28J60 click where the reset line (RST pin on the mikrobus port) needs to be pulled high.
What drivers do is not relevant to the binding. Describe the hardware.
Here's the list of pins in mikroBUS connector: Analog - AN Reset - RST SPI Chip Select - CS SPI Clock - SCK SPI Master Input Slave Output - MISO SPI Master Output Slave Input - MOSI VCC-3.3V power - +3.3V Reference Ground - GND PWM - PWM output INT - Hardware Interrupt RX - UART Receive TX - UART Transmit SCL - I2C Clock SDA - I2C Data +5V - VCC-5V power GND - Reference Ground
Additionally, some new mikroBUS boards contain 1-wire EEPROM that contains a manifest to describe the addon board to provide plug and play capabilities.
My problem with this is that it purports to be some generic description of the connector but it appears to be very centred on a particular use case (this beagle product) with simple add-on boards or those that support the auto-detection eeprom. For other use cases I'm at a loss for why I'd not omit this node from my DT and treat the mikroebus connector like any other header on my boards, where I just apply an overlay that hooks up the device to the relevant spi/pwm/i2c/etc controllers.
I'd almost go as far as to say that this binding is misleading, because it's worded like a complete description of the port but actually only seems to describe a (set of) use case(s). What am I missing?
Link: https://www.mikroe.com/mikrobus Link: https://download.mikroe.com/documents/standards/mikrobus/mikrobus-standard-s... mikroBUS specification Link: https://www.mikroe.com/sht1x-click SHT15 Click Link: https://www.mikroe.com/eth-click ENC28J60 Click Link: https://www.mikroe.com/clickid ClickID
Co-developed-by: Vaishnav M A vaishnav@beagleboard.org Signed-off-by: Vaishnav M A vaishnav@beagleboard.org Signed-off-by: Ayush Singh ayushdevel1325@gmail.com
+required:
- compatible
- pinctrl-0
- pinctrl-1
- pinctrl-2
- pinctrl-3
- pinctrl-4
- pinctrl-5
- pinctrl-6
- pinctrl-7
- pinctrl-8
- i2c-adapter
- spi-controller
- spi-cs
- uart
- pwms
- mikrobus-gpios
Oh also, you're missing properties for the supplies.