Hi Andrew,
On Fri, Jul 5, 2024 at 6:34 PM Andrew Davis <afd@xxxxxx> wrote:
> On 7/5/24 3:01 AM, Geert Uytterhoeven wrote:
> > On Thu, 27 Jun 2024, 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 {
> >
> > Let's use just "&mikrobus" instead...
> >
> >>> 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?
> >
> > You teach fdtoverlay[*] to translate anchors, e.g.
> >
> > fdtoverlay -i base.dtb -o final.dtb \
> > -t mikrobus=mikrobus0 click1.dtbo \
> > -t mikrobus=mikrobus1 click2.dtbo
> >
>
> This basic idea is where I started also, the result is we end
> up needing a huge number of "anchor" points. And they would
> also be board specific. So we would want to store all these
> anchor points in a file, and what better file than another
> DT file.
Why wouldn't a single anchor point suffice?
For Mikrobus, the anchor point should have well-known subnodes
like "spi", "i2c", ... which would take care of the translation.
> Putting all the translations in a DT file to allow the DT overlay
> to become generic is the core idea of this series[0] (looks like
> you already found it, linking for other following along).
>
> And as you note, the symbol table trick allows us to do this
> without teaching fdtoverlay anything new, so it should work
> as-is today for any project already supporting overlays.
Yes, and it sounds cool!
> > I believe the Raspberry Pi people already have something like that.
> >
> > The mikrobus node handles all other translations (e.g. mapping from
> > Mikrobus pins to GPIO numbers), so you do not have to handle these
> > explicitly when adding an overlay.
>
> This part seems to still be an open item. For pinmux we can name
> the pinmux nodes such that their phandles are resolved on overlay
> application. For Pin number/name to GPIO number we have "gpio-names",
> and the names can also be generic. But for Interrupts and a couple
> others, we are still missing a good way to provide a generic mapping
> from pin name to number.
Isn't that the purpose of nexus nodes in the DT spec?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
