On Sat, Mar 03, 2018 at 03:46:33AM +0000, Luke Kenneth Casson Leighton wrote:
On Sat, Mar 3, 2018 at 2:44 AM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
excellent, can you look up the status of A20 and the devicetree fragments?
There has been some work on HDMI on the A10/A20 in October (merged in 4.15): https://www.spinics.net/lists/devicetree/msg198941.html Reportedly, HDMI works now. I'm not sure what else was/is missing.
the *full* hardware set is needed. except for NAND, which has been removed from 2.7.5.
I understand.
But I'm not deeply familiar with the A20 and don't have one around for testing, so I don't now how close we are to that goal.
About DT fragments: I'm not sure what you mean exactly. Mainline support devicetree overlays which should do (half of) the job for EOMA68, though.
Turns out I was wrong about this. Mainline supports the bare core functionality to apply/unapply DT overlays, but it doesn't expose this functionality to userspace.
ah, yes, that's the official name. overlays.
question: do you know if they've added the patches to *REMOVE* overlays yet? Cards could potentially be dynamically removed... or at least put into sleep / suspend only to wake up with a totally different Housing.
The tricky part would be figuring out how the same overlay can be used on base devicetrees for different SoCs, as the exposed busses will have different names.
... i'm not sure what you're referring to, here. do you have an example?
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>.
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"?
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?
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.
Thanks, Jonathan
--- Because it might be of interest to some who aren't familiar with devicetree source syntax, let's go over that example line by line:
eoma68: connector {
A new node is defined. Nodes start with a name and an opening curly bracket. The node is named "connector". Its path would be /.../connector, depending on the names of the outer nodes.
A label "eoma68" points at this node, so the node can be referenced in other places without using the full path.
compatible = "eoma,eoma68-connector";
This is a property of the connector node. It only has a name and a value. Every property and node is terminated with a semicolon.
The "compatible" property tells the OS that the device described by this node is an EOMA68 connector, and allows the right drivers to be selected. The syntax of a "compatible" string is vendor,device.
i2c = <&i2c3>;
This property's value is a "phandle" (property handle). It points at the node with the label "i2c3".
gpios = <&gpio0 0 &gpio2 14 ... >;
In this property, we see pairs of data: A phandle pointing at a GPIO controller, and a plain number, representing the GPIO pin within that GPIO controller.
spi = <&spi4>; ...
More properties.
};
This is the end of the node.
The meaning of all these properties is specified in a devicetree "binding". An example of a DT binding is that of the Allwinner A10's SPI controller, which is also used in the A20: https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-sun4i.t...
There's also a devicetree specification, available at: https://www.devicetree.org/specifications/