[Arm-netbook] Devicetree (was: Re: Testing: GPIO)

Sun Mar 4 00:20:39 GMT 2018

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 at 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 at 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.txt

There's also a devicetree specification, available at:
https://www.devicetree.org/specifications/