On Sun, Mar 4, 2018 at 12:20 AM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
Let's say you have an expansion board that connects to a pair of UART pins and has a bluetooth module on it (simplifying here, because EOMA68 is more complex than necessary for this example).
On A20 you might want to use the UART controller at 0x1c28800 (just an example), which has the label uart2. But on RK3399 you might want to use the UART at 0xff180000, labeled uart0. Now the overlay for A20 would look something like this:
/plugin/; / { ...
fragment@0 { target = <&uart2>; __overlay__ { bluetooth { compatible = "brcm,bcm43438-bt"; max-speed = <921600>; }; }; };};
But for RK3399, you'd have to change that to target = <&uart0>.
ok so i thought that was taken care of by using numerical ids. you'd then place the main device-tree definition in a reference.
i'm sure this can be taken care of by having a definition of EOMA68 (by name) where things like <&uart0> are placed *into* that definition on a per-CPU (per Card) basis.
so you would just have different "implementations" of the EOMA68 Standard pinouts in each Card dtb.
This may be solved by a future iteration of this patchset: https://www.spinics.net/lists/kernel/msg2710913.html
there's nothing mentioned about what standard he's referring to. is there a link, or can you do a quick summary?
This snippet? "It would be good to have a way to expose #<list>-cells types of providers through a connector in a standard way." (That's the only occurence of "standard" on that page)
This work is about coming up with a convention (a "standard" in the general sense) to express the remapping of, at first, GPIOs in DT to give them consistent names from the point of view of an expansion interface.
Or did you mean something else by "what standard he's referring to"?
apologies, i just don't have any context... and damnit i have such a lot else i'm doing at the moment, on deadlines, that i'm not able to fully focus
The other side of the DT job is the dynamic loading of a devicetree overlay based on the EEPROM of the connected housing.
yes that's correct.
Mainline Linux doesn't have something like capemgr[1], AFAIK; But I think this could also be handled in userspace.
it has to be handled in u-boot (at least partially).
Why in u-boot? u-boot won't be around to do something when the card is hot-plugged, right?
u-boot may need to know that it has to pull up certain GPIOs in order to switch on the LCD so that people can choose what to do. it may need to know *that* there is an LCD (and what type).
all that information can only be safely obtained by identifying the Housing through its EEPROM ID.
And then there's the question of how the kernel/userspace is supposed to know on which i2c bus it finds the EOMA68 EEPROM.
good point. the bus utilised will be in the Card's devicetree file: it will have to be named as such.
(Somewhat answering my own question:) I guess there could be something like a DT node that collects all the pieces that go into the EOMA68 interface:
eoma68: connector { compatible = "eoma,eoma68-connector"; gpios = <&gpio0 0 &gpio2 14 ... >; i2c = <&i2c3>; spi = <&spi4>; ... };And then the overlays could be written to always attach to &eoma68.
yes. that's how i imagined it would work.
l.