Post by Luke Kenneth Casson LeightonOn Sat, Mar 3, 2018 at 2:44 AM, Jonathan Neuschäfer
Post by Jonathan NeuschäferPost by Luke Kenneth Casson Leightonexcellent, 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.
Post by Luke Kenneth Casson LeightonPost by Jonathan NeuschäferAbout 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.
Post by Luke Kenneth Casson Leightonah, 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.
Post by Jonathan NeuschäferThe 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/;
/ {
...
***@0 {
target = <&uart2>;
__overlay__ {
bluetooth {
compatible = "brcm,bcm43438-bt";
max-speed = <921600>;
};
};
};
};
But for RK3399, you'd have to change that to target = <&uart0>.
Post by Luke Kenneth Casson LeightonPost by Jonathan NeuschäferThis 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"?
Post by Luke Kenneth Casson LeightonPost by Jonathan NeuschäferThe 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.
Post by Jonathan NeuschäferMainline 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?
Post by Luke Kenneth Casson LeightonPost by Jonathan NeuschäferAnd then there's the question of how the kernel/userspace is supposed to
know on which i2c bus it finds the EOMA68 EEPROM.
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.txt
There's also a devicetree specification, available at:
https://www.devicetree.org/specifications/
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-ne