| Message ID | 20240627-mikrobus-scratch-spi-v5-1-9e6c148bf5f0@beagleboard.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | misc: Add mikroBUS driver | expand |
Hi, Could you give us a DT snippet of how this should look like with a board? On Thu Jun 27, 2024 at 6:26 PM CEST, Ayush Singh wrote: > + board: > + description: board attached to mikrobus connector > + $ref: /schemas/types.yaml#/definitions/phandle-array Shouldn't this be a subnode of the connector? i.e. connector { compatible = "mikrobus-connector"; // phandles to the parent controllers spi { temp-sensor@0 { compatible = "maxim,max31855k"; reg = <0>; }; }; i2c { .. }; }; I don't think you can introduce a new compatible = "maxim,max31855k", "mikrobus,spi"; if there is already a binding for "maxim,max31855k". But I might be wrong. Why is this compatible needed at all? Also, the mikrobus-connector driver could translate the chipselects. -michael
On 6/27/24 22:42, Michael Walle wrote: > Hi, > > Could you give us a DT snippet of how this should look like with a > board? > > On Thu Jun 27, 2024 at 6:26 PM CEST, Ayush Singh wrote: >> + board: >> + description: board attached to mikrobus connector >> + $ref: /schemas/types.yaml#/definitions/phandle-array > Shouldn't this be a subnode of the connector? > > i.e. > > connector { > compatible = "mikrobus-connector"; > > // phandles to the parent controllers > > spi { > temp-sensor@0 { > compatible = "maxim,max31855k"; > reg = <0>; > }; > }; > > i2c { > .. > }; > }; > > I don't think you can introduce a new > compatible = "maxim,max31855k", "mikrobus,spi"; > if there is already a binding for "maxim,max31855k". But I might be > wrong. Why is this compatible needed at all? So I did consider the design you just proposed, but I was not able to solve a few issues. 1. How to deal with say 2 mikrobus connectors in a single system? My goal is to have only 1 overlay required for the board config at most. Ideally, I would actually like to add the dt for most mikroBUS boards to upstream and thus only the following overlay would be required: ``` &connector0 { board = <&temp-board>; }; ``` The problem with making it children is that each connector will require seperate overlays for board configs. Additionally, there are boards with 1 wire eeprom available which can theselves store the overlay. In the current setup it will look as follows: ``` &mikrobus_board { thermo-sensor { ... }; }; ``` Which is completely independent of the connector. If the same can be achieved with child-node as well, then I am open to doing that. > > Also, the mikrobus-connector driver could translate the chipselects. > > -michael Yes, so it is currently doing that. Translating chip select name to the actual number. I am doing it the name way since some boards might use pins other than CS as chipselect and not all connectors will allow all pins to be used as chipselect. Ayush Singh
Hi, On Thu Jun 27, 2024 at 7:29 PM CEST, Ayush Singh wrote: > On 6/27/24 22:42, Michael Walle wrote: > > > Hi, > > > > Could you give us a DT snippet of how this should look like with a > > board? > > > > On Thu Jun 27, 2024 at 6:26 PM CEST, Ayush Singh wrote: > >> + board: > >> + description: board attached to mikrobus connector > >> + $ref: /schemas/types.yaml#/definitions/phandle-array > > Shouldn't this be a subnode of the connector? > > > > i.e. > > > > connector { > > compatible = "mikrobus-connector"; > > > > // phandles to the parent controllers > > > > spi { > > temp-sensor@0 { > > compatible = "maxim,max31855k"; > > reg = <0>; > > }; > > }; > > > > i2c { > > .. > > }; > > }; > > > > I don't think you can introduce a new > > compatible = "maxim,max31855k", "mikrobus,spi"; > > if there is already a binding for "maxim,max31855k". But I might be > > wrong. Why is this compatible needed at all? > > So I did consider the design you just proposed, but I was not able to > solve a few issues. > > 1. How to deal with say 2 mikrobus connectors in a single system? Yes, interesting problem. That info should go into the cover letter. > My goal is to have only 1 overlay required for the board config at most. > Ideally, I would actually like to add the dt for most mikroBUS boards to > upstream and thus only the following overlay would be required: > > ``` > > &connector0 { > > board = <&temp-board>; > > }; That's then per board, per click board. right? > > ``` > > > The problem with making it children is that each connector will require > seperate overlays for board configs. Right. > Additionally, there are boards with 1 wire eeprom available which can > theselves store the overlay. In the current setup it will look as follows: > > ``` > > &mikrobus_board { Where is that phandle pointing to? And what if there are two boards? > > thermo-sensor { > > ... > > }; > > }; But here you can have subnodes, no? These could then be just enumerated as usual. &mikrobus_board { mikrobus_gpio: gpio { gpio-controller; #gpio-cells = <1>; }; spi { cs-gpios = <&mikrobus_gpio 1>; spi@0 { compatible = "mydevice"; reg = <0>; }; }; }; > ``` Not sure what this is, but my mail reader doesn't render RST? ;) -michael > > Which is completely independent of the connector. If the same can be > achieved with child-node as well, then I am open to doing that. > > > > > > Also, the mikrobus-connector driver could translate the chipselects. > > > > -michael > > Yes, so it is currently doing that. Translating chip select name to the > actual number. I am doing it the name way since some boards might use > pins other than CS as chipselect and not all connectors will allow all > pins to be used as chipselect. > > > Ayush Singh
> That's then per board, per click board. right? > > > > > ``` > > > > > > The problem with making it children is that each connector will require > > seperate overlays for board configs. > > Right. For somebody who has not used overlays, could you expand on that. Is it not possible to say "Overlay this DT fragment on point X of the tree". So you populate children on a node. It should not matter if you have the same children somewhere else, they have different parents? Andrew
On Thu, Jun 27, 2024 at 09:56:11PM +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 uart, > spi, i2c, pwm and other buses. Additionally, some new mikroBUS boards > contain 1-wire EEPROM that contains a manifest to describe the addon > board to provide plug and play capabilities. > > A mikroBUS addon board is free to leave some of the pins unused which > are marked as NC or Not Connected. > > 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. > > Some SPI addon boards use other pins like RST, AN etc as chipselect (eg. > SPI Extend Click). Thus, `spi-cs` and `spi-cs-names` property is added > to allow mikroBUS addon board to specify chipselect by name. > > Here's the list of pins in mikroBUS connector: > AN - Analog > RST - Reset > CS - SPI Chip Select > SCK - SPI Clock > MISO - SPI Master Input Slave Output > MOSI - SPI Master Output Slave Input > +3.3V - VCC-3.3V power > GND - Reference Ground > 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 > > Link: https://www.mikroe.com/mikrobus > Link: > https://download.mikroe.com/documents/standards/mikrobus/mikrobus-standard-specification-v200.pdf > 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/spi-extend-click SPI Extend Click > > Co-developed-by: Vaishnav M A <vaishnav@beagleboard.org> > Signed-off-by: Vaishnav M A <vaishnav@beagleboard.org> > Signed-off-by: Ayush Singh <ayush@beagleboard.org> > --- > .../bindings/connector/mikrobus-connector.yaml | 107 +++++++++++++++++++++ > MAINTAINERS | 6 ++ > 2 files changed, 113 insertions(+) > > diff --git a/Documentation/devicetree/bindings/connector/mikrobus-connector.yaml b/Documentation/devicetree/bindings/connector/mikrobus-connector.yaml > new file mode 100644 > index 000000000000..033479f8604f > --- /dev/null > +++ b/Documentation/devicetree/bindings/connector/mikrobus-connector.yaml > @@ -0,0 +1,107 @@ > +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/connector/mikrobus-connector.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: mikroBUS add-on board connector > + > +maintainers: > + - Ayush Singh <ayush@beagleboard.org> > + > +properties: > + compatible: > + const: mikrobus-connector > + > + pinctrl-0: true > + pinctrl-1: true > + pinctrl-2: true > + pinctrl-3: true > + pinctrl-4: true > + pinctrl-5: true > + pinctrl-6: true > + pinctrl-7: true > + pinctrl-8: true > + > + pinctrl-names: > + minItems: 1 > + maxItems: 9 > + items: > + enum: [default, pwm_default, pwm_gpio, uart_default, uart_gpio, i2c_default, i2c_gpio, spi_default, > + spi_gpio] Generally, each pinctrl-N is mutually exclusive. It looks like here you want multiple states active at one time. Does this work? > + > + spi-controller: > + description: spi-controller of mikroBUS SPI pins along with cs pins. > + $ref: /schemas/types.yaml#/definitions/phandle > + > + spi-cs: > + description: spi chip-select corresponding to the chip-selects on the mikrobus socket. Wrap lines at 80 char. The array index is the chip-select number on the connector and the value is the host SPI controller CS numbers? Or the other way around? This needs a better description. > + $ref: /schemas/types.yaml#/definitions/uint32-array Maximum number of entries? > + > + spi-cs-names: > + minItems: 1 > + maxItems: 12 > + items: > + enum: [default, pwm, int, rx, tx, scl, sda, an, rst, sck, cipo, copi] > + > + i2c-controller: > + description: i2c controller attached to the mikrobus socket. > + $ref: /schemas/types.yaml#/definitions/phandle i2c-bus is the somewhat standard property for this. Really, I'd expect connectors to look something like this: connector { i2c-0 { i2c-bus = <&i2c3>; #address-cells = <1>; #size-cells = <0>; device@12 { compatible = "some-i2c-device"; }; }; }; That form allows for multiple buses (of the same type or different) on the connector. > + > + uart-controller: > + description: uart controller attached to the mikrobus socket > + $ref: /schemas/types.yaml#/definitions/phandle > + > + pwms: > + description: the pwm-controller corresponding to the mikroBUS PWM pin. > + maxItems: 1 > + > + mikrobus-gpios: > + minItems: 1 > + maxItems: 12 > + > + mikrobus-gpio-names: The GPIO binding does not work this way as the name is in the property. Either drop if you want to keep the array or you have to do something like this: pwm-gpios int-gpios rx-gpios Really, the intention was for connectors to use gpio-map property to renumber GPIOs relative to the connector. > + minItems: 1 > + maxItems: 12 > + items: > + enum: [pwm, int, rx, tx, scl, sda, an, rst, cs, sck, cipo, copi] > + > + board: > + description: board attached to mikrobus connector > + $ref: /schemas/types.yaml#/definitions/phandle-array What is this for? > + > +required: > + - compatible > + - pinctrl-0 > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/gpio/gpio.h> > + mikrobus { > + compatible = "mikrobus-connector"; > + pinctrl-names = "default", "pwm_default", "pwm_gpio","uart_default", "uart_gpio", "i2c_default", > + "i2c_gpio", "spi_default", "spi_gpio"; > + pinctrl-0 = <&P2_03_gpio_input_pin &P1_04_gpio_pin &P1_02_gpio_pin>; > + pinctrl-1 = <&P2_01_pwm_pin>; > + pinctrl-2 = <&P2_01_gpio_pin>; > + pinctrl-3 = <&P2_05_uart_pin &P2_07_uart_pin>; > + pinctrl-4 = <&P2_05_gpio_pin &P2_07_gpio_pin>; > + pinctrl-5 = <&P2_09_i2c_pin &P2_11_i2c_pin>; > + pinctrl-6 = <&P2_09_gpio_pin &P2_11_gpio_pin>; > + pinctrl-7 = <&P1_12_spi_pin &P1_10_spi_pin &P1_08_spi_sclk_pin &P1_06_spi_cs_pin>; > + pinctrl-8 = <&P1_12_gpio_pin &P1_10_gpio_pin &P1_08_gpio_pin &P1_06_gpio_pin>; > + pwms = <&ehrpwm1 0 500000 0>; > + i2c-controller = <&i2c1>; > + uart-controller = <&uart1>; > + spi-controller = <&spi1>; > + spi-cs = <0 1>; > + spi-cs-names = "default", "rst"; > + mikrobus-gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>, <&gpio0 23 GPIO_ACTIVE_HIGH>, > + <&gpio0 30 GPIO_ACTIVE_HIGH>, <&gpio0 31 GPIO_ACTIVE_HIGH>, > + <&gpio0 15 GPIO_ACTIVE_HIGH>, <&gpio0 14 GPIO_ACTIVE_HIGH>, > + <&gpio0 4 GPIO_ACTIVE_HIGH>, <&gpio0 3 GPIO_ACTIVE_HIGH>, > + <&gpio0 2 GPIO_ACTIVE_HIGH>, <&gpio0 5 GPIO_ACTIVE_HIGH>, > + <&gpio2 25 GPIO_ACTIVE_HIGH>, <&gpio2 3 GPIO_ACTIVE_HIGH>; > + }; > diff --git a/MAINTAINERS b/MAINTAINERS > index 807feae089c4..8e4115e93aeb 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -15108,6 +15108,12 @@ M: Oliver Neukum <oliver@neukum.org> > S: Maintained > F: drivers/usb/image/microtek.* > > +MIKROBUS > +M: Ayush Singh <ayush@beagleboard.org> > +M: Vaishnav M A <vaishnav@beagleboard.org> > +S: Maintained > +F: Documentation/devicetree/bindings/connector/mikrobus-connector.yaml > + > MIKROTIK CRS3XX 98DX3236 BOARD SUPPORT > M: Luka Kovacic <luka.kovacic@sartura.hr> > M: Luka Perkov <luka.perkov@sartura.hr> > > -- > 2.45.2 >
On Thu, Jun 27, 2024 at 10:59:46PM +0530, Ayush Singh wrote: > On 6/27/24 22:42, Michael Walle wrote: > > > Hi, > > > > Could you give us a DT snippet of how this should look like with a > > board? > > > > On Thu Jun 27, 2024 at 6:26 PM CEST, Ayush Singh wrote: > > > + board: > > > + description: board attached to mikrobus connector > > > + $ref: /schemas/types.yaml#/definitions/phandle-array > > Shouldn't this be a subnode of the connector? > > > > i.e. > > > > connector { > > compatible = "mikrobus-connector"; > > > > // phandles to the parent controllers These are per bus, so put them in the child bus nodes: > > > > spi { spi-bus = <&spiN>; spi-cs = ... The base DT would have the spi node and these properties. The overlay would still apply to the connector node, but also have the 'spi' node along with the devices. Note that whatever is done here, I expect to work on any connector with SPI, I2C, etc. So structuring the bindings for that would be nice. There is also this effort which needs the same bindings[1]. > > temp-sensor@0 { > > compatible = "maxim,max31855k"; > > reg = <0>; > > }; > > }; > > > > i2c { > > .. > > }; > > }; > > > > I don't think you can introduce a new > > compatible = "maxim,max31855k", "mikrobus,spi"; > > if there is already a binding for "maxim,max31855k". But I might be > > wrong. Why is this compatible needed at all? > > So I did consider the design you just proposed, but I was not able to solve > a few issues. > > 1. How to deal with say 2 mikrobus connectors in a single system? I don't understand why that's a problem? It's no different than the same overlay working on multiple vendor's boards which I imagine you want too. The connector node in the base DT has to remap everything from base DT into a mikrobus defined number/name space. For example, host GPIO N is mapped to mikrobus connector GPIO 0 and so on. There is one issue in knowing what the target node is. Standardizing the target path or connector node label only works for 1 connector per system. You can have an empty target path in the overlay and something else can decide the target. This is what's being done for overlays with the dynamic PCI nodes. For example, maybe an eeprom tells the driver what overlay to apply. Rob [1] https://lore.kernel.org/all/20240510-hotplug-drm-bridge-v2-0-ec32f2c66d56@bootlin.com/
On 6/28/24 21:58, Rob Herring wrote: > On Thu, Jun 27, 2024 at 09:56:11PM +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 uart, >> spi, i2c, pwm and other buses. Additionally, some new mikroBUS boards >> contain 1-wire EEPROM that contains a manifest to describe the addon >> board to provide plug and play capabilities. >> >> A mikroBUS addon board is free to leave some of the pins unused which >> are marked as NC or Not Connected. >> >> 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. >> >> Some SPI addon boards use other pins like RST, AN etc as chipselect (eg. >> SPI Extend Click). Thus, `spi-cs` and `spi-cs-names` property is added >> to allow mikroBUS addon board to specify chipselect by name. >> >> Here's the list of pins in mikroBUS connector: >> AN - Analog >> RST - Reset >> CS - SPI Chip Select >> SCK - SPI Clock >> MISO - SPI Master Input Slave Output >> MOSI - SPI Master Output Slave Input >> +3.3V - VCC-3.3V power >> GND - Reference Ground >> 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 >> >> Link: https://www.mikroe.com/mikrobus >> Link: >> https://download.mikroe.com/documents/standards/mikrobus/mikrobus-standard-specification-v200.pdf >> 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/spi-extend-click SPI Extend Click >> >> Co-developed-by: Vaishnav M A <vaishnav@beagleboard.org> >> Signed-off-by: Vaishnav M A <vaishnav@beagleboard.org> >> Signed-off-by: Ayush Singh <ayush@beagleboard.org> >> --- >> .../bindings/connector/mikrobus-connector.yaml | 107 +++++++++++++++++++++ >> MAINTAINERS | 6 ++ >> 2 files changed, 113 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/connector/mikrobus-connector.yaml b/Documentation/devicetree/bindings/connector/mikrobus-connector.yaml >> new file mode 100644 >> index 000000000000..033479f8604f >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/connector/mikrobus-connector.yaml >> @@ -0,0 +1,107 @@ >> +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/connector/mikrobus-connector.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: mikroBUS add-on board connector >> + >> +maintainers: >> + - Ayush Singh <ayush@beagleboard.org> >> + >> +properties: >> + compatible: >> + const: mikrobus-connector >> + >> + pinctrl-0: true >> + pinctrl-1: true >> + pinctrl-2: true >> + pinctrl-3: true >> + pinctrl-4: true >> + pinctrl-5: true >> + pinctrl-6: true >> + pinctrl-7: true >> + pinctrl-8: true >> + >> + pinctrl-names: >> + minItems: 1 >> + maxItems: 9 >> + items: >> + enum: [default, pwm_default, pwm_gpio, uart_default, uart_gpio, i2c_default, i2c_gpio, spi_default, >> + spi_gpio] > Generally, each pinctrl-N is mutually exclusive. It looks like here you > want multiple states active at one time. Does this work? I see. In mikrobus case, these pinctrl are not mutually exclusive. The ones that are mutually exclusive are as follows: - pwm_default and pwm_gpio - uart_default and uart_gpio - i2c_default and i2c_gpio - spi_default and spi_gpio It still does lead to 16 combinations so not sure if it is the best approach. >> + >> + spi-controller: >> + description: spi-controller of mikroBUS SPI pins along with cs pins. >> + $ref: /schemas/types.yaml#/definitions/phandle >> + >> + spi-cs: >> + description: spi chip-select corresponding to the chip-selects on the mikrobus socket. > Wrap lines at 80 char. > > The array index is the chip-select number on the connector and the > value is the host SPI controller CS numbers? Or the other way around? > This needs a better description. > >> + $ref: /schemas/types.yaml#/definitions/uint32-array > Maximum number of entries? > >> + >> + spi-cs-names: >> + minItems: 1 >> + maxItems: 12 >> + items: >> + enum: [default, pwm, int, rx, tx, scl, sda, an, rst, sck, cipo, copi] >> + >> + i2c-controller: >> + description: i2c controller attached to the mikrobus socket. >> + $ref: /schemas/types.yaml#/definitions/phandle > i2c-bus is the somewhat standard property for this. > > Really, I'd expect connectors to look something like this: > > connector { > i2c-0 { > i2c-bus = <&i2c3>; > #address-cells = <1>; > #size-cells = <0>; > device@12 { > compatible = "some-i2c-device"; > }; > }; > }; > > That form allows for multiple buses (of the same type or different) on > the connector. > >> + >> + uart-controller: >> + description: uart controller attached to the mikrobus socket >> + $ref: /schemas/types.yaml#/definitions/phandle >> + >> + pwms: >> + description: the pwm-controller corresponding to the mikroBUS PWM pin. >> + maxItems: 1 >> + >> + mikrobus-gpios: >> + minItems: 1 >> + maxItems: 12 >> + >> + mikrobus-gpio-names: > The GPIO binding does not work this way as the name is in the property. > Either drop if you want to keep the array or you have to do something > like this: > > pwm-gpios > int-gpios > rx-gpios > > Really, the intention was for connectors to use gpio-map property to > renumber GPIOs relative to the connector. Can you point me to what you mean by gpio-map property? >> + minItems: 1 >> + maxItems: 12 >> + items: >> + enum: [pwm, int, rx, tx, scl, sda, an, rst, cs, sck, cipo, copi] >> + >> + board: >> + description: board attached to mikrobus connector >> + $ref: /schemas/types.yaml#/definitions/phandle-array > What is this for? > >> + >> +required: >> + - compatible >> + - pinctrl-0 >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + #include <dt-bindings/gpio/gpio.h> >> + mikrobus { >> + compatible = "mikrobus-connector"; >> + pinctrl-names = "default", "pwm_default", "pwm_gpio","uart_default", "uart_gpio", "i2c_default", >> + "i2c_gpio", "spi_default", "spi_gpio"; >> + pinctrl-0 = <&P2_03_gpio_input_pin &P1_04_gpio_pin &P1_02_gpio_pin>; >> + pinctrl-1 = <&P2_01_pwm_pin>; >> + pinctrl-2 = <&P2_01_gpio_pin>; >> + pinctrl-3 = <&P2_05_uart_pin &P2_07_uart_pin>; >> + pinctrl-4 = <&P2_05_gpio_pin &P2_07_gpio_pin>; >> + pinctrl-5 = <&P2_09_i2c_pin &P2_11_i2c_pin>; >> + pinctrl-6 = <&P2_09_gpio_pin &P2_11_gpio_pin>; >> + pinctrl-7 = <&P1_12_spi_pin &P1_10_spi_pin &P1_08_spi_sclk_pin &P1_06_spi_cs_pin>; >> + pinctrl-8 = <&P1_12_gpio_pin &P1_10_gpio_pin &P1_08_gpio_pin &P1_06_gpio_pin>; >> + pwms = <&ehrpwm1 0 500000 0>; >> + i2c-controller = <&i2c1>; >> + uart-controller = <&uart1>; >> + spi-controller = <&spi1>; >> + spi-cs = <0 1>; >> + spi-cs-names = "default", "rst"; >> + mikrobus-gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>, <&gpio0 23 GPIO_ACTIVE_HIGH>, >> + <&gpio0 30 GPIO_ACTIVE_HIGH>, <&gpio0 31 GPIO_ACTIVE_HIGH>, >> + <&gpio0 15 GPIO_ACTIVE_HIGH>, <&gpio0 14 GPIO_ACTIVE_HIGH>, >> + <&gpio0 4 GPIO_ACTIVE_HIGH>, <&gpio0 3 GPIO_ACTIVE_HIGH>, >> + <&gpio0 2 GPIO_ACTIVE_HIGH>, <&gpio0 5 GPIO_ACTIVE_HIGH>, >> + <&gpio2 25 GPIO_ACTIVE_HIGH>, <&gpio2 3 GPIO_ACTIVE_HIGH>; >> + }; >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 807feae089c4..8e4115e93aeb 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -15108,6 +15108,12 @@ M: Oliver Neukum <oliver@neukum.org> >> S: Maintained >> F: drivers/usb/image/microtek.* >> >> +MIKROBUS >> +M: Ayush Singh <ayush@beagleboard.org> >> +M: Vaishnav M A <vaishnav@beagleboard.org> >> +S: Maintained >> +F: Documentation/devicetree/bindings/connector/mikrobus-connector.yaml >> + >> MIKROTIK CRS3XX 98DX3236 BOARD SUPPORT >> M: Luka Kovacic <luka.kovacic@sartura.hr> >> M: Luka Perkov <luka.perkov@sartura.hr> >> >> -- >> 2.45.2 >> I am switching to child-node based structure from the next patch since I was able to replicate applying board overlay on a generic connector with child node. Ayush Singh
On Tue, Jul 2, 2024 at 9:14 AM Ayush Singh <ayush@beagleboard.org> wrote: > > On 6/28/24 21:58, Rob Herring wrote: > > > On Thu, Jun 27, 2024 at 09:56:11PM +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-gpios: > >> + minItems: 1 > >> + maxItems: 12 > >> + > >> + mikrobus-gpio-names: > > The GPIO binding does not work this way as the name is in the property. > > Either drop if you want to keep the array or you have to do something > > like this: > > > > pwm-gpios > > int-gpios > > rx-gpios > > > > Really, the intention was for connectors to use gpio-map property to > > renumber GPIOs relative to the connector. > > Can you point me to what you mean by gpio-map property? It is defined in the DT specification. Rob
>> But here you can have subnodes, no? These could then be just >> enumerated as usual. >> >> &mikrobus_board { >> mikrobus_gpio: gpio { >> gpio-controller; >> #gpio-cells = <1>; >> }; >> >> spi { >> cs-gpios = <&mikrobus_gpio 1>; >> >> spi@0 { >> compatible = "mydevice"; >> reg = <0>; >> }; >> }; >> }; >> Hi, I am now working on an approach for mikroBUS based on the apprach described here: [1] I am thinking of the gpio-controller approach you seem to have used here. So I wanted to inquire if there already exists a gpio-controller driver that can create a proxy controller that forwards stuff to the underlying actual controller. So something like the following: &mikrobus_gpio: gpio { gpio-controller; #gpio-cells = <2>; gpios = <&gpio1 0>, <&gpi2 1>; }; spi { cs-gpios = <&mikrobus_gpio 1 GPIO_ACTIVE_HIGH>; }; There does exist gpio0-virtio, but that seems to be for vm context. [1]: https://lore.kernel.org/linux-arm-kernel/20240702164403.29067-1-afd@ti.com/ Ayush Singh
On Sat, Aug 31, 2024 at 1:11 PM Ayush Singh <ayush@beagleboard.org> wrote: > > >> But here you can have subnodes, no? These could then be just > >> enumerated as usual. > >> > >> &mikrobus_board { > >> mikrobus_gpio: gpio { > >> gpio-controller; > >> #gpio-cells = <1>; > >> }; > >> > >> spi { > >> cs-gpios = <&mikrobus_gpio 1>; > >> > >> spi@0 { > >> compatible = "mydevice"; > >> reg = <0>; > >> }; > >> }; > >> }; > >> > > Hi, I am now working on an approach for mikroBUS based on the apprach > described here: [1] > > > I am thinking of the gpio-controller approach you seem to have used > here. So I wanted to inquire if there already exists a gpio-controller > driver that can create a proxy controller that forwards stuff to the > underlying actual controller. gpio-map is what you are looking for. It's documented in the DT spec. It was created exactly for this purpose of remapping GPIO lines on a connector. Rob
>> gpio-map is what you are looking for. It's documented in the DT spec. >> It was created exactly for this purpose of remapping GPIO lines on a >> connector. >> >> Rob Hi. I found docs on nexus nodes [1] and tried using it for mikroBUS, but it does not seem to be working. Here is my connector: ``` mikrobus_gpio0: mikrobus-gpio0 { #gpio-cells = <2>; gpio-map = <0 0 &main_gpio1 11 0>, <1 0 &main_gpio1 9 0>, <2 0 &main_gpio1 24 0>, <3 0 &main_gpio1 25 0>, <4 0 &main_gpio1 22 0>, <5 0 &main_gpio1 23 0>, <6 0 &main_gpio1 7 0>, <7 0 &main_gpio1 8 0>, <8 0 &main_gpio1 14 0>, <9 0 &main_gpio1 13 0>, <10 0 &main_gpio1 12 0>, <11 0 &main_gpio1 10 0>; gpio-map-mask = <0xf 0x0>; gpio-map-pass-thru = <0x0 0x1>; }; ... &main_uart5 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&mikrobus_uart_pins_default>; gnss { compatible = "u-blox,neo-8"; reset-gpios = <&mikrobus_gpio0 10 GPIO_ACTIVE_LOW>; }; }; ``` After some fdtdump, I can see that at least the dtc compiler does not seem to do the forwarding at dt compile time. Here is the dump: ``` mikrobus-gpio0 { #gpio-cells = <0x00000002>; gpio-map = <0x00000000 0x00000000 0x00000025 0x0000000b 0x00000000 0x00000001 0x00000000 0x00000025 0x00000009 0x00000000 0x00000002 0x00000000 0x00000025 0x00000018 0x00000000 0x00000003 0x00000000 0x00000025 0x00000019 0x00000000 0x00000004 0x00000000 0x00000025 0x00000016 0x00000000 0x00000005 0x00000000 0x00000025 0x00000017 0x00000000 0x00000006 0x00000000 0x00000025 0x00000007 0x00000000 0x00000007 0x00000000 0x00000025 0x00000008 0x00000000 0x00000008 0x00000000 0x00000025 0x0000000e 0x00000000 0x00000009 0x00000000 0x00000025 0x0000000d 0x00000000 0x0000000a 0x00000000 0x00000025 0x0000000c 0x00000000 0x0000000b 0x00000000 0x00000025 0x0000000a 0x00000000>; gpio-map-mask = <0x0000000f 0x00000000>; gpio-map-pass-thru = <0x00000000 0x00000001>; phandle = <0x0000000e>; }; ... serial@2850000 { compatible = "ti,am64-uart", "ti,am654-uart"; reg = <0x00000000 0x02850000 0x00000000 0x00000100>; interrupts = <0x00000000 0x000000b7 0x00000004>; power-domains = <0x00000003 0x0000009c 0x00000001>; clocks = <0x00000002 0x0000009c 0x00000000>; clock-names = "fclk"; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <0x0000000d>; phandle = <0x00000081>; gnss { compatible = "u-blox,neo-8"; reset-gpios = <0x0000000e 0x0000000a 0x00000001>; }; }; ``` So I am a bit unsure. Is the dtc parser in the kernel supposed to do the mapping, or is it supposed to be done by `dtc` at compile time? Maybe we do not have support for it in upstream kernel yet? Or maybe I am missing something? [1]: https://devicetree-specification.readthedocs.io/en/v0.3/devicetree-basics.html#nexus-nodes-and-specifier-mapping Ayush Singh
On Wed, Sep 4, 2024 at 12:09 PM Ayush Singh <ayush@beagleboard.org> wrote: > > >> gpio-map is what you are looking for. It's documented in the DT spec. > >> It was created exactly for this purpose of remapping GPIO lines on a > >> connector. > >> > >> Rob > > > Hi. I found docs on nexus nodes [1] and tried using it for mikroBUS, but > it does not seem to be working. Here is my connector: > > ``` > > mikrobus_gpio0: mikrobus-gpio0 { > #gpio-cells = <2>; > gpio-map = > <0 0 &main_gpio1 11 0>, <1 0 &main_gpio1 9 0>, > <2 0 &main_gpio1 24 0>, <3 0 &main_gpio1 25 0>, > <4 0 &main_gpio1 22 0>, <5 0 &main_gpio1 23 0>, > <6 0 &main_gpio1 7 0>, <7 0 &main_gpio1 8 0>, > <8 0 &main_gpio1 14 0>, <9 0 &main_gpio1 13 0>, > <10 0 &main_gpio1 12 0>, <11 0 &main_gpio1 10 0>; > gpio-map-mask = <0xf 0x0>; > gpio-map-pass-thru = <0x0 0x1>; > }; > > ... > > &main_uart5 { > status = "okay"; > pinctrl-names = "default"; > pinctrl-0 = <&mikrobus_uart_pins_default>; > > gnss { > compatible = "u-blox,neo-8"; > reset-gpios = <&mikrobus_gpio0 10 GPIO_ACTIVE_LOW>; > }; > }; > > ``` > > > After some fdtdump, I can see that at least the dtc compiler does not > seem to do the forwarding at dt compile time. Here is the dump: dtc knows nothing about it. > ``` > > mikrobus-gpio0 { > #gpio-cells = <0x00000002>; > gpio-map = <0x00000000 0x00000000 0x00000025 0x0000000b > 0x00000000 0x00000001 0x00000000 0x00000025 0x00000009 0x00000000 > 0x00000002 0x00000000 0x00000025 0x00000018 0x00000000 0x00000003 > 0x00000000 0x00000025 0x00000019 0x00000000 0x00000004 0x00000000 > 0x00000025 0x00000016 0x00000000 0x00000005 0x00000000 0x00000025 > 0x00000017 0x00000000 0x00000006 0x00000000 0x00000025 0x00000007 > 0x00000000 0x00000007 0x00000000 0x00000025 0x00000008 0x00000000 > 0x00000008 0x00000000 0x00000025 0x0000000e 0x00000000 0x00000009 > 0x00000000 0x00000025 0x0000000d 0x00000000 0x0000000a 0x00000000 > 0x00000025 0x0000000c 0x00000000 0x0000000b 0x00000000 0x00000025 > 0x0000000a 0x00000000>; > gpio-map-mask = <0x0000000f 0x00000000>; > gpio-map-pass-thru = <0x00000000 0x00000001>; > phandle = <0x0000000e>; > }; You might need "gpio-controller" here. Though if you do, I think that's a mistake in the kernel. It should work like interrupt-map and generally you have either interrupt-controller or interrupt-map, but not both (though that is allowed now too). > ... > > serial@2850000 { > compatible = "ti,am64-uart", "ti,am654-uart"; > reg = <0x00000000 0x02850000 0x00000000 0x00000100>; > interrupts = <0x00000000 0x000000b7 0x00000004>; > power-domains = <0x00000003 0x0000009c 0x00000001>; > clocks = <0x00000002 0x0000009c 0x00000000>; > clock-names = "fclk"; > status = "okay"; > pinctrl-names = "default"; > pinctrl-0 = <0x0000000d>; > phandle = <0x00000081>; > gnss { > compatible = "u-blox,neo-8"; > reset-gpios = <0x0000000e 0x0000000a 0x00000001>; > }; > }; > > ``` > > > So I am a bit unsure. Is the dtc parser in the kernel supposed to do the No such thing as "dtc parser in the kernel". > mapping, or is it supposed to be done by `dtc` at compile time? No. > Maybe we > do not have support for it in upstream kernel yet? Yes, there is upstream support. Grep for of_parse_phandle_with_args_map. Rob
On 9/4/24 23:19, Rob Herring wrote: > On Wed, Sep 4, 2024 at 12:09 PM Ayush Singh <ayush@beagleboard.org> wrote: >>>> gpio-map is what you are looking for. It's documented in the DT spec. >>>> It was created exactly for this purpose of remapping GPIO lines on a >>>> connector. >>>> >>>> Rob >> >> Hi. I found docs on nexus nodes [1] and tried using it for mikroBUS, but >> it does not seem to be working. Here is my connector: >> >> ``` >> >> mikrobus_gpio0: mikrobus-gpio0 { >> #gpio-cells = <2>; >> gpio-map = >> <0 0 &main_gpio1 11 0>, <1 0 &main_gpio1 9 0>, >> <2 0 &main_gpio1 24 0>, <3 0 &main_gpio1 25 0>, >> <4 0 &main_gpio1 22 0>, <5 0 &main_gpio1 23 0>, >> <6 0 &main_gpio1 7 0>, <7 0 &main_gpio1 8 0>, >> <8 0 &main_gpio1 14 0>, <9 0 &main_gpio1 13 0>, >> <10 0 &main_gpio1 12 0>, <11 0 &main_gpio1 10 0>; >> gpio-map-mask = <0xf 0x0>; >> gpio-map-pass-thru = <0x0 0x1>; >> }; >> >> ... >> >> &main_uart5 { >> status = "okay"; >> pinctrl-names = "default"; >> pinctrl-0 = <&mikrobus_uart_pins_default>; >> >> gnss { >> compatible = "u-blox,neo-8"; >> reset-gpios = <&mikrobus_gpio0 10 GPIO_ACTIVE_LOW>; >> }; >> }; >> >> ``` >> >> >> After some fdtdump, I can see that at least the dtc compiler does not >> seem to do the forwarding at dt compile time. Here is the dump: > dtc knows nothing about it. > >> ``` >> >> mikrobus-gpio0 { >> #gpio-cells = <0x00000002>; >> gpio-map = <0x00000000 0x00000000 0x00000025 0x0000000b >> 0x00000000 0x00000001 0x00000000 0x00000025 0x00000009 0x00000000 >> 0x00000002 0x00000000 0x00000025 0x00000018 0x00000000 0x00000003 >> 0x00000000 0x00000025 0x00000019 0x00000000 0x00000004 0x00000000 >> 0x00000025 0x00000016 0x00000000 0x00000005 0x00000000 0x00000025 >> 0x00000017 0x00000000 0x00000006 0x00000000 0x00000025 0x00000007 >> 0x00000000 0x00000007 0x00000000 0x00000025 0x00000008 0x00000000 >> 0x00000008 0x00000000 0x00000025 0x0000000e 0x00000000 0x00000009 >> 0x00000000 0x00000025 0x0000000d 0x00000000 0x0000000a 0x00000000 >> 0x00000025 0x0000000c 0x00000000 0x0000000b 0x00000000 0x00000025 >> 0x0000000a 0x00000000>; >> gpio-map-mask = <0x0000000f 0x00000000>; >> gpio-map-pass-thru = <0x00000000 0x00000001>; >> phandle = <0x0000000e>; >> }; > You might need "gpio-controller" here. Though if you do, I think > that's a mistake in the kernel. It should work like interrupt-map and > generally you have either interrupt-controller or interrupt-map, but > not both (though that is allowed now too). > >> ... >> >> serial@2850000 { >> compatible = "ti,am64-uart", "ti,am654-uart"; >> reg = <0x00000000 0x02850000 0x00000000 0x00000100>; >> interrupts = <0x00000000 0x000000b7 0x00000004>; >> power-domains = <0x00000003 0x0000009c 0x00000001>; >> clocks = <0x00000002 0x0000009c 0x00000000>; >> clock-names = "fclk"; >> status = "okay"; >> pinctrl-names = "default"; >> pinctrl-0 = <0x0000000d>; >> phandle = <0x00000081>; >> gnss { >> compatible = "u-blox,neo-8"; >> reset-gpios = <0x0000000e 0x0000000a 0x00000001>; >> }; >> }; >> >> ``` >> >> >> So I am a bit unsure. Is the dtc parser in the kernel supposed to do the > No such thing as "dtc parser in the kernel". > >> mapping, or is it supposed to be done by `dtc` at compile time? > No. > >> Maybe we >> do not have support for it in upstream kernel yet? > Yes, there is upstream support. Grep for of_parse_phandle_with_args_map. > > Rob So, after a bit of troubleshooting, it seems that a nexus node should not be present at root level (unless it also has an actual driver). If the nexus node is a root node without an actual driver, anything referring to the node is deferred. I am still a bit unsure if I should make the `mikrobus-connector` itself a nexus node or if I should have a subnode named `mikrobus_gpio`, but at least things seem to be working now. So, thanks for your help. Ayush Singh
diff --git a/Documentation/devicetree/bindings/connector/mikrobus-connector.yaml b/Documentation/devicetree/bindings/connector/mikrobus-connector.yaml new file mode 100644 index 000000000000..033479f8604f --- /dev/null +++ b/Documentation/devicetree/bindings/connector/mikrobus-connector.yaml @@ -0,0 +1,107 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/connector/mikrobus-connector.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: mikroBUS add-on board connector + +maintainers: + - Ayush Singh <ayush@beagleboard.org> + +properties: + compatible: + const: mikrobus-connector + + pinctrl-0: true + pinctrl-1: true + pinctrl-2: true + pinctrl-3: true + pinctrl-4: true + pinctrl-5: true + pinctrl-6: true + pinctrl-7: true + pinctrl-8: true + + pinctrl-names: + minItems: 1 + maxItems: 9 + items: + enum: [default, pwm_default, pwm_gpio, uart_default, uart_gpio, i2c_default, i2c_gpio, spi_default, + spi_gpio] + + spi-controller: + description: spi-controller of mikroBUS SPI pins along with cs pins. + $ref: /schemas/types.yaml#/definitions/phandle + + spi-cs: + description: spi chip-select corresponding to the chip-selects on the mikrobus socket. + $ref: /schemas/types.yaml#/definitions/uint32-array + + spi-cs-names: + minItems: 1 + maxItems: 12 + items: + enum: [default, pwm, int, rx, tx, scl, sda, an, rst, sck, cipo, copi] + + i2c-controller: + description: i2c controller attached to the mikrobus socket. + $ref: /schemas/types.yaml#/definitions/phandle + + uart-controller: + description: uart controller attached to the mikrobus socket + $ref: /schemas/types.yaml#/definitions/phandle + + pwms: + description: the pwm-controller corresponding to the mikroBUS PWM pin. + maxItems: 1 + + mikrobus-gpios: + minItems: 1 + maxItems: 12 + + mikrobus-gpio-names: + minItems: 1 + maxItems: 12 + items: + enum: [pwm, int, rx, tx, scl, sda, an, rst, cs, sck, cipo, copi] + + board: + description: board attached to mikrobus connector + $ref: /schemas/types.yaml#/definitions/phandle-array + +required: + - compatible + - pinctrl-0 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + mikrobus { + compatible = "mikrobus-connector"; + pinctrl-names = "default", "pwm_default", "pwm_gpio","uart_default", "uart_gpio", "i2c_default", + "i2c_gpio", "spi_default", "spi_gpio"; + pinctrl-0 = <&P2_03_gpio_input_pin &P1_04_gpio_pin &P1_02_gpio_pin>; + pinctrl-1 = <&P2_01_pwm_pin>; + pinctrl-2 = <&P2_01_gpio_pin>; + pinctrl-3 = <&P2_05_uart_pin &P2_07_uart_pin>; + pinctrl-4 = <&P2_05_gpio_pin &P2_07_gpio_pin>; + pinctrl-5 = <&P2_09_i2c_pin &P2_11_i2c_pin>; + pinctrl-6 = <&P2_09_gpio_pin &P2_11_gpio_pin>; + pinctrl-7 = <&P1_12_spi_pin &P1_10_spi_pin &P1_08_spi_sclk_pin &P1_06_spi_cs_pin>; + pinctrl-8 = <&P1_12_gpio_pin &P1_10_gpio_pin &P1_08_gpio_pin &P1_06_gpio_pin>; + pwms = <&ehrpwm1 0 500000 0>; + i2c-controller = <&i2c1>; + uart-controller = <&uart1>; + spi-controller = <&spi1>; + spi-cs = <0 1>; + spi-cs-names = "default", "rst"; + mikrobus-gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>, <&gpio0 23 GPIO_ACTIVE_HIGH>, + <&gpio0 30 GPIO_ACTIVE_HIGH>, <&gpio0 31 GPIO_ACTIVE_HIGH>, + <&gpio0 15 GPIO_ACTIVE_HIGH>, <&gpio0 14 GPIO_ACTIVE_HIGH>, + <&gpio0 4 GPIO_ACTIVE_HIGH>, <&gpio0 3 GPIO_ACTIVE_HIGH>, + <&gpio0 2 GPIO_ACTIVE_HIGH>, <&gpio0 5 GPIO_ACTIVE_HIGH>, + <&gpio2 25 GPIO_ACTIVE_HIGH>, <&gpio2 3 GPIO_ACTIVE_HIGH>; + }; diff --git a/MAINTAINERS b/MAINTAINERS index 807feae089c4..8e4115e93aeb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15108,6 +15108,12 @@ M: Oliver Neukum <oliver@neukum.org> S: Maintained F: drivers/usb/image/microtek.* +MIKROBUS +M: Ayush Singh <ayush@beagleboard.org> +M: Vaishnav M A <vaishnav@beagleboard.org> +S: Maintained +F: Documentation/devicetree/bindings/connector/mikrobus-connector.yaml + MIKROTIK CRS3XX 98DX3236 BOARD SUPPORT M: Luka Kovacic <luka.kovacic@sartura.hr> M: Luka Perkov <luka.perkov@sartura.hr>