On 6/27/24 22:51, Michael Walle wrote:
On Thu Jun 27, 2024 at 7:07 PM CEST, Andrew Davis wrote:
+ mikrobus_boards {
+ thermo_click: thermo-click {
+ compatible = "maxim,max31855k", "mikrobus-spi";
I might be missing something, but your solution cannot possibly be
to list every click board that could be connected (all 1500+ of them)
to every mikroBUS connector on every device's DT file..
Each click board should have a single DTSO overlay file to describe the
click board, one per click board total. And then that overlay should
apply cleanly to any device that has a mikroBUS interface.
Which means you have not completely solved the fundamental problem of
abstracting the mikroBUS connector in DT. Each of these click device child
nodes has to be under the parent connector node. Which means a phandle
to the parent node, which is not generically named. For instance
if my board has 2 connectors, I would have mikrobus0 and mikrobus1,
the click board's overlay would look like this:
/dts-v1/;
/plugin/;
&mikrobus0 {
status = "okay";
mikrobus_board {
thermo-click {
compatible = "maxim,max31855k", "mikrobus-spi";
spi-max-frequency = <1000000>;
pinctrl-apply = "spi_default";
};
};
};
If there should only be one DT overlay per click board, how would
you apply that to to different connectors?
See my other two replies for more context:
https://lore.kernel.org/linux-arm-kernel/cef08d49-a462-4167-8b9d-bf09e8aac92f@xxxxxxxxxxxxxxx/
https://lore.kernel.org/linux-arm-kernel/e0f9754e-4d84-4ab4-82a4-34cb12800927@xxxxxxxxxxxxxxx/
My ideal design is that most mikroBUS board configs will be defined in a
`dtsi` file which can be included by any system with mikroBUS support.
This file might look as follows:
```
/dts-v1/;
/plugin/;
/ {
mikrobus_boards {
thermo_click: thermo-click {
compatible = "maxim,max31855k", "mikrobus-spi";
spi-max-frequency = <1000000>;
pinctrl-apply = "spi_default";
};
lsm6dsl_click: lsm6dsl-click {
compatible = "st,lsm6ds3", "mikrobus-spi";
spi-max-frequency = <1000000>;
pinctrl-apply = "spi_default";
};
};
};
```
And the board overlay will look as follows:
```
&conector {
board = <&lsm6dsl_click>;
};
```
I do have an experimental configfs entry that passes the mikroBUS board
id(s) and creates and applies the dt changeset to the connector dynamically.
I think this solution is almost there, but once you solve the above
issue, we could just apply the right overlay for our attached click
board ahead of time and not need the mikroBUS bus driver at all.
The bus driver would still be needed to do the enumeration of the
children, no? And it could make the chip select translations etc. So
you can use the normal bindings of these devices.
-michael
If static dt was the only method to detect the board, then it would be
fine. But boards with 1-wire-eeprom can allow for for dynamic detection
if the overlay can be system agnostic.
To make the dt system agnostic, it should be possible for the board to
specify the following information:
1. If a pin is supposed to perform its normal function (UART TX should
actually do UART TX), or if it should work as say GPIO (Eg, using RST
pin as SPI chipselect).
2. Which pin(s) are the SPI chipselect.
3. If a particular pin needs to be pulled high or low for the board to
function, etc.
So while most of the normal properties of SPI devices can be reused,
there is a need to introduce new properties for additional information.
In the previous patches, MikroBUS manifest was being used for this
purpose, but for a full dt driver, the device tree needs to be extended
to specify these extra properties that are not relevant to the
non-mikrobus variant of the device.
Ayush Singh
