Re: devicetree live reconfigureable hardware (eoma68)

[Luke Kenneth Casson Leighton]

hi pantelis, don't freak out, but the best introduction i can think of
to what occurred to me is, "arg fek that is an ecumenical matter!
[1]".

*deep breath* - i can forsee a need for parameterisation to be added
to the proposed connector objects in some fashion.  justification /
explanation follows.

if you recall, i mentioned previously the idea of having dtsi
fragments which, in effect, allow an interface instance to select "pin
1 of interface is to be a GPIO" by some form of naming convention [aka
connector objects] or "pins 2, 3, 4 and 5 are to be SPI NSS, CLK, MOSI
and MISO respectively".

the problem is, that's nowhere near enough.  for example, i have a
board where one of the pins is a power-up for the 3.3v regulator.  if
that regulator isn't enabled, USB is offline, the SD/MMC is offline -
all of which saves power, and also, importantly, when things are
"floating" [i.e. the CPU card itself is powered down], the 3.3v
regulator is *also* powered down.  this is important because the board
is battery-operated.  i mention this because someone might suggest,
"but why don't you just pull up that GPIO pin to HIGH with a
resistor?" - answer, "because that would drain the battery".

so that fragmentation previously mentioned - where SD/MMC "fragments"
have to be created, one for SD/MMC in 1-pin mode, one for SD/MMC in
2-pin mode, one for 4-pin mode, and so on... that now applies for GPIO
*as well*.

in other words, a .dtsi file [or entry, or connector object] would
need to be created which specifies:

"pin 1 on the interface is a GPIO, and it's an input"
"pin 1 on the interface is a GPIO, and it's an output, defaulting to
push-push type, HIGH"
....

you can see where this is going.  each of those required states is
near-identical.  we could even name them [i'm assuming that names may
include brackets]:

"pin1_is_gpio(input,0,0)"
"pin1_is_gpio(output,0,1)"
...

which very much looks like functions, with parameters.  and if it
looks like parameters, and smells like parameters, where the
definitions of those connector objects are near-identical except for a
one-to-one correspondance between the parameters in the name and the
purpose _behind_ those parameters, then, logically and undeniably, it
makes sense to actually *make* them parameters [and, by inference, to
have support for macros / functions in devicetree].

the advantage here would then be that things like the GPIO that's to
be used as a pin-select on SD/MMC becomes.... a parameter.

much as i am reluctant to suggest it, it has to be voiced: the next
logical extension would be some form of switch statement / conditional
selection, based on a parameter's value, allowing decisions to be made
as to whether SPI should be 3-wire or 4-wire, whether SD/MMC should be
1, 2, 4 bus width or SPI-mode compatible, and so on.

the alternative is this dog's dinner set of near-identical pre-defined
hard-coded set of all possible entries that could ever possibly exist.
which, now that i think about it, _could_ be auto-generated using some
scripted programming / macro language e.g. python, perl, bash or m4,
"gcc -E" and so on.

i believe you'll then find that there are significant benefits to the
concept of macros/functions as part of devicetree: i think you'll find
that there will be some drastic simplification and reduction in the
size of some of the dts and dtsi files.  looking at the sunxi files
for the very first time over the past 24 hours, i notice an alarming
amount of duplication of near-identical segments.

l.

[1] https://www.youtube.com/watch?v=2TQuacxEjAU
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/