hi folks,
i raised the issue of dynamic reconfigureable hardware back in 2012,
and thank you (once again) to alan for kindly answering:
https://lkml.org/lkml/2012/3/10/71
since then, yaay! beaglebone with "capes" has driven some
modifications to the linux kernel:
http://events.linuxfoundation.org/sites/events/files/slides/dynamic-dt-elce14.pdf
the hardware differences between beaglebone capes and EOMA68 hardware
is that EOMA68 CPU Cards may remain powered up whilst being removed
from a "chassis" (whether it be a laptop, a tablet, an engineering
board, a desktop - whatever) and plugged into a new one [i'm sure that
it's theoretically possible for beaglebone capes to be carefully
removed from a live-running beagleboard but i certainly wouldn't like
to try it].
the difference between the beaglebone cape on-board EEPROM and the
original idea that i came up with for EOMA68 is that the on-board
EEPROM in EOMA68 would contain actual device-tree configurations
describing the plugin-hardware, whereas from what i can gather
beaglebone cape EEPROMs merely contain an "identifier".
so, first thing that a CPU Card does is: read the EEPROM data, get the
various device-trees in it, and start totally reconfiguring the 68
pins and associated hardware. not a problem, right? weelll... :)
here's the problem that i see, perhaps someone could tell me an
appropriate place to discuss this (if LKML isn't), and if the issue i
describe has already been catered for and is easily (and conveniently)
solvable.
first, EOMA68 is 68 pins, many of which share a GPIO function. so,
for example, the UART TX and RX pins may also be multiplexed to plain
GPIO. likewise all of the pins of SPI as well as SD/MMC, these may be
GPIO - just like with the beaglebone capes.
so, first complication: it is necessary to select "SD/MMC" interface
instead of the GPIO functions.... but then, 5 minutes later, whoops,
we have to select GPIO pins. but, remember, there are at present
*three* totally different CPU Cards (based on the allwinner a20,
another on the ingenic jz4775, and a 64-bit ARM card is being
designed).
to clarify that: beaglebone is {1}-Board to {M}-Many-Capes, whereas
EOMA68 is {N}-CPUCards to {M}-Chassis.
so whereas with the beaglebone it's perfectly fine to just hard-code
"oh yeah, pin 50 is GPIO but it's also multiplexed with SD CLK line",
with EOMA68 it is simply flat-out impossible to do that. you simply
cannot know, in the future, what GPIO will be connected on a CPU Card.
the *only* information that you have is, "EOMA68 pin 16 is GPIO0 or SD
Data line 3". you have *NO IDEA* what *actual* GPIO that goes to on a
particular SoC, especially ones that will be available over the next
decade.
so that's complication (1).
however, there is a secondary complication in that a hardware designer
may choose *not* to use *all* of the pins associated with a particular
hardware function. so for example, with SPI, it is possible to use
the 4-wire variant which has DDR capability (100mbytes/sec which is
pretty awesome, thanks to intel's work i believe). or, you could go
down to a 2-wire data width bus. or, you could go back to the
standard 4-wire configuration (NSS, CLK, MOSI, MISO), *or* you could
do the 3-wire SPI variant which is uniplexed single-wire data for both
transmit and send (NSS, CLK, MOSI shared). and, not only that, but if
someone decides they don't want to use the standard NSS wire, that's
fine - they can use another GPIO pin for NSS!
another example: SD/MMC. it's either SPI-compatibility mode (3 or 4
wire), or it's a 1-wire SD/MMC data bus, or a 2-wire, or a 4-wire bus.
oh, and there's a "Card Detect" GPIO... which is also optional, and
you use polling instead of EINT IRQ on that wire!
how in god's green earth are you supposed to describe this in
reconfigureable device-tree blocks??? :)
should we write:
* one device-tree file to describe the SPI 4-wire DDR mode
* one for the SPI 2-wire DDR mode
* one for the SPI 4-wire standard variant
* one for the SPI 3-wire standard variant
* one for... o fuk i forgot that you need to double those up because
of the NSS possibly being a different GPIO pin...
argh now we have *EIGHT* possible device-tree files to dynamically
choose from... and that's just the SPI interface!
now we have to do the same thing for SD/MMC... that's what... eight
possible device-tree files to choose from there, as well??
and we haven't started on the RGB/TTL interface yet! there's even the
possibility, with the RGB/TTL interface, that it could be connected to
a converter IC, where a standard monitor (DVI, VGA) with EDID
capability could be connected to it. oh and don't forget that it
could be 18-bit output or 15-bit output.
possible solution, here, which solves both complication (1) as well as
complication (2): a level of abstraction is needed. the abstraction
is needed because, as mentioned in complication (1) the only
consistent naming is in the EOMA68 interface, *NOT* in the SoCs
*BEHIND* the EOMA68 interface.
the only possible way at the moment to do that is, i believe, to use
device tree "includes". there would be files, on each SoC's kernel,
such as this:
* eoma68_pin_1_when_configured_as_gpio.dtsi
* eoma68_pin_35_when_configured_as_gpio.dtsi
* .... gpio ...
* etc.
and then:
* eoma68_sdmmc_in_4wire_data_mode.dtsi
* eoma68_sdmmc_in_2wire_data_mode.dtsi
* eoma68_sdmmc_in_1wire_data_mode.dtsi
* eoma68_sdmmc_in_spi_mode.dtsi
and so on and so forth.
then, having those available as well-known library files, which are
guaranteed to cover all and every possibility, a "Chassis" may then
have a single devicetree file which comprises:
/include/ eoma68_pin_1_when_configured_as_gpio.dtsi
....
....
and pretty much nothing else.
absolutely insane and guaranteed to make even the most sensible linux
kernel programmer spew and hurl their lunch, projectile-vomit-fashion,
over a deep and wide area.
so.
first question.
is there *anything* in devicetree that has a level of abstraction
where all these capabilities may be compressed into a single file?
naming, classes, anything? the thought of splitting things up into
almost 100 separate dtsi files is genuinely making me cringe.
i have an even more horrible idea of overloading phandles, like
setting a variable "eoma68_pin_1_as_gpio = <0xe0680001>" or something
like that - using the phandle 32-bit values as a predefined convention
that, when it comes to loading the devicetree file off the chassis
EEPROM, those predefined 32-bit conventions are the necessary
abstraction.
... but honestly, it would be much much better to have strings, not
32-bit values.
any other ideas out there?
now, for anyone considering that this discussion might be irrelevant,
consider this: in the near future (if it hasn't happened already) some
bright spark is going to realise that the beaglebone "capes" is a
ready-made market for creating a far superior "compatible" form-factor
engineering board - perhaps something with a dual-core or quad-core
processor... just like has *already* happened with arduinos.
in other words, the current beaglebone black hardware expansion
interface becomes a de-facto industry standard, just like the arduino
shield interface already is [the only reason we haven't had this come
up in the linux kernel community with arduino shields and boards
already is because arduino boards aren't powerful enough to run the
linux kernel].
the implications there are that in a relatively short time, beaglebone
"capes" will likely turn from a 1-to-many scenario into the exact same
many-to-many scenario as faced by EOMA68 hardware right now. if not
beaglebone, then something else.
so this is *not* a theoretical problem, isolated to a single hardware
design, it's a generic problem that's going to present itself and
smack people in the teeth fairly shortly. yaay! :)
l.
> On Nov 7, 2015, at 19:36 , Luke Kenneth Casson Leighton <[email protected]> wrote:
>
> hi folks,
>
Hi Luke,
This is a quite lengthy treatise you wrote here.
I was not very familiar with EOMA68 so I hit the web to read about
it first. At first glance it seems quite reasonable.
> i raised the issue of dynamic reconfigureable hardware back in 2012,
> and thank you (once again) to alan for kindly answering:
> https://lkml.org/lkml/2012/3/10/71
>
> since then, yaay! beaglebone with "capes" has driven some
> modifications to the linux kernel:
> http://events.linuxfoundation.org/sites/events/files/slides/dynamic-dt-elce14.pdf
>
> the hardware differences between beaglebone capes and EOMA68 hardware
> is that EOMA68 CPU Cards may remain powered up whilst being removed
> from a "chassis" (whether it be a laptop, a tablet, an engineering
> board, a desktop - whatever) and plugged into a new one [i'm sure that
> it's theoretically possible for beaglebone capes to be carefully
> removed from a live-running beagleboard but i certainly wouldn't like
> to try it].
There is no support for hotplug (yet) for beaglebone capes.
There is no real software reason, it’s just that the hardware is not designed
for it.
>
> the difference between the beaglebone cape on-board EEPROM and the
> original idea that i came up with for EOMA68 is that the on-board
> EEPROM in EOMA68 would contain actual device-tree configurations
> describing the plugin-hardware, whereas from what i can gather
> beaglebone cape EEPROMs merely contain an "identifier”.
I would caution against putting the device tree configuration in the
storage of the expansion board. While appealing at first IMHO we are
not at a point where device tree blobs are perfectly forward compatible.
For some of the messy details about why, please take a look at the excellent
presentation that Thomas Petazzoni made:
http://free-electrons.com/pub/conferences/2015/elc/petazzoni-dt-as-stable-abi-fairy-tale/petazzoni-dt-as-stable-abi-fairy-tale.pdf
The identifier can be easily mapped to a device tree blob object from
the filesystem which we can update in lockstep with the kernel.
>
> so, first thing that a CPU Card does is: read the EEPROM data, get the
> various device-trees in it, and start totally reconfiguring the 68
> pins and associated hardware. not a problem, right? weelll... :)
>
> here's the problem that i see, perhaps someone could tell me an
> appropriate place to discuss this (if LKML isn't), and if the issue i
> describe has already been catered for and is easily (and conveniently)
> solvable.
>
> first, EOMA68 is 68 pins, many of which share a GPIO function. so,
> for example, the UART TX and RX pins may also be multiplexed to plain
> GPIO. likewise all of the pins of SPI as well as SD/MMC, these may be
> GPIO - just like with the beaglebone capes.
>
> so, first complication: it is necessary to select "SD/MMC" interface
> instead of the GPIO functions.... but then, 5 minutes later, whoops,
> we have to select GPIO pins. but, remember, there are at present
> *three* totally different CPU Cards (based on the allwinner a20,
> another on the ingenic jz4775, and a 64-bit ARM card is being
> designed).
>
> to clarify that: beaglebone is {1}-Board to {M}-Many-Capes, whereas
> EOMA68 is {N}-CPUCards to {M}-Chassis.
>
> so whereas with the beaglebone it's perfectly fine to just hard-code
> "oh yeah, pin 50 is GPIO but it's also multiplexed with SD CLK line",
> with EOMA68 it is simply flat-out impossible to do that. you simply
> cannot know, in the future, what GPIO will be connected on a CPU Card.
> the *only* information that you have is, "EOMA68 pin 16 is GPIO0 or SD
> Data line 3". you have *NO IDEA* what *actual* GPIO that goes to on a
> particular SoC, especially ones that will be available over the next
> decade.
>
> so that's complication (1).
>
We are already (me and gcl) trying to design something that will address
this problem. And no, your EOMA68 boards are not the first ones to hit it.
The 96board family has the same problem, all the boards with arduino compatible
headers have the same problem, etc..
> however, there is a secondary complication in that a hardware designer
> may choose *not* to use *all* of the pins associated with a particular
> hardware function. so for example, with SPI, it is possible to use
> the 4-wire variant which has DDR capability (100mbytes/sec which is
> pretty awesome, thanks to intel's work i believe). or, you could go
> down to a 2-wire data width bus. or, you could go back to the
> standard 4-wire configuration (NSS, CLK, MOSI, MISO), *or* you could
> do the 3-wire SPI variant which is uniplexed single-wire data for both
> transmit and send (NSS, CLK, MOSI shared). and, not only that, but if
> someone decides they don't want to use the standard NSS wire, that's
> fine - they can use another GPIO pin for NSS!
>
> another example: SD/MMC. it's either SPI-compatibility mode (3 or 4
> wire), or it's a 1-wire SD/MMC data bus, or a 2-wire, or a 4-wire bus.
> oh, and there's a "Card Detect" GPIO... which is also optional, and
> you use polling instead of EINT IRQ on that wire!
>
> how in god's green earth are you supposed to describe this in
> reconfigureable device-tree blocks??? :)
>
> should we write:
>
> * one device-tree file to describe the SPI 4-wire DDR mode
> * one for the SPI 2-wire DDR mode
> * one for the SPI 4-wire standard variant
> * one for the SPI 3-wire standard variant
> * one for... o fuk i forgot that you need to double those up because
> of the NSS possibly being a different GPIO pin...
>
> argh now we have *EIGHT* possible device-tree files to dynamically
> choose from... and that's just the SPI interface!
>
> now we have to do the same thing for SD/MMC... that's what... eight
> possible device-tree files to choose from there, as well??
>
> and we haven't started on the RGB/TTL interface yet! there's even the
> possibility, with the RGB/TTL interface, that it could be connected to
> a converter IC, where a standard monitor (DVI, VGA) with EDID
> capability could be connected to it. oh and don't forget that it
> could be 18-bit output or 15-bit output.
>
>
> possible solution, here, which solves both complication (1) as well as
> complication (2): a level of abstraction is needed. the abstraction
> is needed because, as mentioned in complication (1) the only
> consistent naming is in the EOMA68 interface, *NOT* in the SoCs
> *BEHIND* the EOMA68 interface.
>
No, that way is madness.
The idea I’m toying with requires the introduction of something called
a ‘connector’ which will deal with all mapping of resources from the
platform agnostic connector format to the internal SoC/CPU card format.
That includes an extension to the notion of pinmuxing to something that
is more abstracted.
So the device tree blobs would be the same for each board that supports
the connector and the resources they define will be mapped either statically
or dynamically using the connector ‘object’ as a translating proxy.
Sorry, I have been quite busy lately so I haven’t been able to post
new patches.
> the only possible way at the moment to do that is, i believe, to use
> device tree "includes". there would be files, on each SoC's kernel,
> such as this:
>
> * eoma68_pin_1_when_configured_as_gpio.dtsi
> * eoma68_pin_35_when_configured_as_gpio.dtsi
> * .... gpio ...
> * etc.
>
> and then:
>
> * eoma68_sdmmc_in_4wire_data_mode.dtsi
> * eoma68_sdmmc_in_2wire_data_mode.dtsi
> * eoma68_sdmmc_in_1wire_data_mode.dtsi
> * eoma68_sdmmc_in_spi_mode.dtsi
>
> and so on and so forth.
>
> then, having those available as well-known library files, which are
> guaranteed to cover all and every possibility, a "Chassis" may then
> have a single devicetree file which comprises:
>
> /include/ eoma68_pin_1_when_configured_as_gpio.dtsi
> ....
> ....
>
> and pretty much nothing else.
>
> absolutely insane and guaranteed to make even the most sensible linux
> kernel programmer spew and hurl their lunch, projectile-vomit-fashion,
> over a deep and wide area.
>
> so.
>
No. Let’s not do that ^^^
> first question.
>
> is there *anything* in devicetree that has a level of abstraction
> where all these capabilities may be compressed into a single file?
> naming, classes, anything? the thought of splitting things up into
> almost 100 separate dtsi files is genuinely making me cringe.
>
> i have an even more horrible idea of overloading phandles, like
> setting a variable "eoma68_pin_1_as_gpio = <0xe0680001>" or something
> like that - using the phandle 32-bit values as a predefined convention
> that, when it comes to loading the devicetree file off the chassis
> EEPROM, those predefined 32-bit conventions are the necessary
> abstraction.
>
> ... but honestly, it would be much much better to have strings, not
> 32-bit values.
>
> any other ideas out there?
>
Nope, don’t do that either :)
> now, for anyone considering that this discussion might be irrelevant,
> consider this: in the near future (if it hasn't happened already) some
> bright spark is going to realise that the beaglebone "capes" is a
> ready-made market for creating a far superior "compatible" form-factor
> engineering board - perhaps something with a dual-core or quad-core
> processor... just like has *already* happened with arduinos.
>
> in other words, the current beaglebone black hardware expansion
> interface becomes a de-facto industry standard, just like the arduino
> shield interface already is [the only reason we haven't had this come
> up in the linux kernel community with arduino shields and boards
> already is because arduino boards aren't powerful enough to run the
> linux kernel].
>
> the implications there are that in a relatively short time, beaglebone
> "capes" will likely turn from a 1-to-many scenario into the exact same
> many-to-many scenario as faced by EOMA68 hardware right now. if not
> beaglebone, then something else.
>
> so this is *not* a theoretical problem, isolated to a single hardware
> design, it's a generic problem that's going to present itself and
> smack people in the teeth fairly shortly. yaay! :)
>
> l.
It’s not a theoretical problem, it’s already hitting people in the face.
You can’t get smacked in the face by a theory.
I’m working on it, hope I’ll have something to present before the Christmas vacations,
but, unfortunately time is limited.
Regards
— Pantelis
On Tue, Nov 10, 2015 at 8:30 PM, Pantelis Antoniou
<[email protected]> wrote:
>
>> On Nov 7, 2015, at 19:36 , Luke Kenneth Casson Leighton <[email protected]> wrote:
>>
>> hi folks,
>>
>
> Hi Luke,
>
> This is a quite lengthy treatise you wrote here.
apologies, i've been working in insolation [mostly hardware] but
thinking about the dynamic configureability issue [since 2011], i
therefore needed to lay out the whole logical reasoning chain. sorry
about that
> I was not very familiar with EOMA68 so I hit the web to read about
> it first. At first glance it seems quite reasonable.
basically it's like phonebloks except they're tackling smartphones,
and i'm [patiently] tackling "everything else". laptops, tablets,
mini-desktops, keyboard-computers, media centres etc. etc. anything
which doesn't end up too bulky if its main computing is on a 5mm x
54mm x 86mm self-enclosed [formerly PCMCIA] case.
end-users are used to the concept of "memory card" being movable and
replaceable and upgradeable and sellable: if this is now "computer
card" it's not such a hard stretch of imagination. people in the
street i tell that to, they like it a lot.
> There is no support for hotplug (yet) for beaglebone capes.
> There is no real software reason, it’s just that the hardware is not designed
> for it.
yeah, understood. it's not really safe to do, either, as you might
plug the pins in off-by-one whilst the power is on. whereas EOMA68 is
basically re-using PCMCIA housings/sockets/assemblies. those *are*
designed for hotplugging, and some of the CPU Cards may be
OTG-powered. so, live hotplugging, whilst i am nervous about trying
it for the first time, is a real possibility.
> I would caution against putting the device tree configuration in the
> storage of the expansion board. While appealing at first IMHO we are
> not at a point where device tree blobs are perfectly forward compatible.
i was thinking more along the lines of dts (source) fragments, not
dtb (binary blob) fragments.... implications of that being that you
may need to activate [i.e. run] the dt compiler from the kernel before
you can access hardware.
> For some of the messy details about why, please take a look at the excellent
> presentation that Thomas Petazzoni made:
>
> http://free-electrons.com/pub/conferences/2015/elc/petazzoni-dt-as-stable-abi-fairy-tale/petazzoni-dt-as-stable-abi-fairy-tale.pdf
>
> The identifier can be easily mapped to a device tree blob object from
> the filesystem which we can update in lockstep with the kernel.
right. thinking out loud, immediate problem is, you don't know
whether - or even if - there is a filesystem *at all*. in some cases,
CPU Cards may not even have a processor. they could be an FPGA card.
or be running the windows OS [at some point.]
to get to the point, then, i feel that "device tree fragments" after
thinking it was a good idea all these years, probably isn't so good
after all.
much better, i feel, would be to still have the device-tree fragments
on the computing module's internal storage, suitably named with
aliases "eoma68_pin_1_as_gpio", and "eoma68_pin_35_as_gpio", then to
have a plaintext [or other well-defined] formatted file, stored in the
EEPROM, that simply is a list of names indicating what the kernel
should pull together to make up the GPIO and functions of the current
chassis the computing module's plugged in to.
this has the advantage that, in the future, when non-gnu-linux OSes
get involved [i have someone who's donated an EOMA68 CPU Card to a
FreeBSD developer for example] it's not so hard for those OSes to
implement their own dynamic reconfigureability... *without* needing to
pull in device-tree interoperability.
the only thing that will be a bit of a bitch is RGB/TTL
configuration. that's.... well, you need hsync, vsync, blah blah
everything basically. all the EDID data and a bit more besides. in
fact... in theeoryyyyy... now that i think about it, it might actually
be possible to _use_ EDID data as the preferred format... hmmmm :)
>> so whereas with the beaglebone it's perfectly fine to just hard-code
>> "oh yeah, pin 50 is GPIO but it's also multiplexed with SD CLK line",
>> with EOMA68 it is simply flat-out impossible to do that. you simply
>> cannot know, in the future, what GPIO will be connected on a CPU Card.
>> the *only* information that you have is, "EOMA68 pin 16 is GPIO0 or SD
>> Data line 3". you have *NO IDEA* what *actual* GPIO that goes to on a
>> particular SoC, especially ones that will be available over the next
>> decade.
>>
>> so that's complication (1).
>>
>
> We are already (me and gcl) trying to design something that will address
> this problem. And no, your EOMA68 boards are not the first ones to hit it.
ok, that's good to know.
> The 96board family has the same problem, all the boards with arduino compatible
> headers have the same problem, etc..
ahh ok. oh right, so there are actually boards out there which are
running the linux kernel [instead of using sdcc / avr-utils] that have
arduino-compatible headers. cool.
>> possible solution, here, which solves both complication (1) as well as
>> complication (2): a level of abstraction is needed. the abstraction
>> is needed because, as mentioned in complication (1) the only
>> consistent naming is in the EOMA68 interface, *NOT* in the SoCs
>> *BEHIND* the EOMA68 interface.
>>
>
> No, that way is madness.
:)
> The idea I’m toying with requires the introduction of something called
> a ‘connector’ which will deal with all mapping of resources from the
> platform agnostic connector format
... e.g. "arduino-connector"...
> to the internal SoC/CPU card format.
> That includes an extension to the notion of pinmuxing to something that
> is more abstracted.
>
> So the device tree blobs would be the same for each board that supports
> the connector and the resources they define will be mapped either statically
> or dynamically using the connector ‘object’ as a translating proxy.
ok. so. we maay be thinking along similar lines, let me
double-check. above, after abandoning the concept of storing dtb
blobs [or dts source files] in the EEPROM, i describe instead a list
of names, each of which refers to a pre-compiled dtsi, the idea being
that these are "stitched together" externally by a little bit of code.
so i believe what you call a connector 'object' as a translating
proxy would do the same job... perhaps even defined in devicetree
fileformat?
if so [connector objects stored in dtb format], then question to
consider: what's to say that the future binary incompatibility issue
mentioned in that pdf won't hit those blobs?
>> i have an even more horrible idea of overloading phandles, like
>> [....]
>>
> Nope, don’t do that either :)
already blanked from my mind. no drugs needed either :)
>> the implications there are that in a relatively short time, beaglebone
>> "capes" will likely turn from a 1-to-many scenario into the exact same
>> many-to-many scenario as faced by EOMA68 hardware right now. if not
>> beaglebone, then something else.
>>
>> [...]
>>
> I’m working on it, hope I’ll have something to present before the Christmas vacations,
awesome.
> but, unfortunately time is limited.
as always... :)
so. main quick question is the format / specification for connector
objects, and what file format they'd be expected to be in. if
"plaintext" [or equivalently-simple] i'd be going "yay!". if not, i'd
be concerned. btw, to clarify: i don't mean that the *specification*
of the actual connector be in plaintext: that should be clear that it
should be in devicetree [or devicetree fragments / includes]. it's
the *instantiation* of a connector that has me concerned. it really
should be nothing more than a list of names, referring to the
[multiplexed] available functions listed in the devicetree file[s].
anything more than that has my alarm bells ringing. not entirely sure
why...
l.
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