On Fri, Mar 15, 2024 at 09:40:13PM +0100, Krzysztof Kozlowski wrote: > On 15/03/2024 21:20, Russell King (Oracle) wrote: > > On Fri, Mar 15, 2024 at 09:09:11PM +0100, Krzysztof Kozlowski wrote: > >>> +properties: > >>> + compatible: > >>> + const: mikrobus-connector > >> > >> Hm, why do you create binding for the connector, not for some sort of > >> controller? Please provide some rationale for this in commit msg. > > > > I think you have a distorted view. I refer you to the Mikroe mikroBUS > > specification - it's _just_ a connector which provides a fairly > > standardised purpose for each pin and the electrical specifications. > > For example of the pins: power, UART, SPIs, I2C, PWM, and analogue > > pins. > > I refer to the commit msg or description in the binding and there is > nothing explained like this. Yeah, true, I could google every possible > bus specification, but I also expect some sort of help here by the patch > submitter. > > The binding looks like binding for a connector, not for some sort of > controller, then are you saying the control part it is purely in > software? That's how DTS looks like, but then my question is are there > some sort of controller which would also perform this? There is, as far as I'm aware, no "controller" for a mikroBUS. As I tried to explain, it's a bunch of pins with defined standard functions. The idea seems to be they're connected to a SoC with a pinmux that can reconfigure the function of the pin. At least that's how the hardware implementations I've seen do it. > > This isn't a choice at all. Here's the list of pins: > > > > 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 > > > > Any data pin can be a GPIO if e.g. a relay board is plugged in, even > > if some of the other pins are used for e.g. UART purposes. For example, > > a GPS board that provides the GPS data over the UART pins, and the > > PPS signal through a different pin. > > And could you not have some certain features supported? Could have some > pins just pull down / not connected? A board plugged in doesn't have to use all the functions. I gave two examples. Apart from the power pins, The GPS board as I stated uses the two UART pins, and some GPS boards route the PPS signal to another pin on the connector, but that's entirely optional. Another pin might be used as a GPIO as an enable. In the case of a relay board I've had, the SPI CS pin is used for one relay, and the PWM pin for the other relay. I also have a BME280 humidity/pressure sensor board, which just uses the two I2C pins. What is supported by a board is down to the board. Which pins it connects to is down to the board. Which board is plugged in is up to the user. That is essentially the long and short of mikroBUS - I hope I've given a good overview of it. I am slightly confused by this series, because it seems the Linux "mikroBUS" layer requires a one-wire EEPROM on the boards, but the official mikroBUS specification doesn't state this. The author really needs to clarify what they are implementing here. Are they truly implementing mikroBUS as defined by Mikroe, or are they implementing someone's custom extension to it that adds an identification EEPROM - in which case I would argue that this code as it stands is not suitable for mainline as long as it purports to be implementing support for Mikroe's mikroBUS. Hence, I think we should back off on reviewing this until we have that clarification. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ greybus-dev mailing list -- greybus-dev@xxxxxxxxxxxxxxxx To unsubscribe send an email to greybus-dev-leave@xxxxxxxxxxxxxxxx
|