[Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions

[Paul Boddie]

On Monday, 20 July 2020 01:38:34 CEST Luke Kenneth Casson Leighton wrote:
> On Sunday, July 19, 2020, Paul Boddie <paul at boddie.org.uk> wrote:
> > 
> > So, there would be the A20 DT itself, the EOMA68-A20 DT which exposes or
> > enables various peripherals,
> 
> so, some peripherals like the otg, mmc0, hdmi and also interestingly the 2
> USB ports despite being on the EOMA68 connector, these would all go in the
> same level as cubietruck i.e. machine level.

Right.

> > and then - at run-time - each housing's DT which
> > activates the peripherals that were exposed but not enabled.
> 
> yes.  the 2nd sdmmc (mmc3 i think), the i2c, uart, spi, rgbttl and eint,
> all those would go into "dynamic pointer default NULL" set.

Yes, and I guess that the rgbttl peripheral would be the thing providing the 
VGA output, so there would potentially be something there with a device tree 
"port" that can connect to a corresponding port in the housing's DT...

[...]

> > For example, how would a VGA output port be defined?
> 
> that ie precisely what the dynamic thing does: it's specified in the
> dynamic fragment.
> 
> the dynamic fragment contains the names eoma68-pin1 to 68 and says that
> when eoma68-pin33 is connected it shall be given the purpose "RGBTTL HSYNC".

How does this correspond to the pinctrl groups that one usually sees? In the 
sun7i-a20.dtsi file there is a pinctrl node with lots of groups defined.

Would there be some kind of "logical" pin group like this...?

&pio {
	eoma68_lcd_pins: eoma68-lcd-pins {
		/* assuming that LCD0 pins are routed via the connector's LCD pins */
		pins = "PD0", "PD1", ... ;
		function = "eoma68-lcd";
	};
};

(Here, I used the sun7i-a20-olinuxino-micro.dts file to provide some hints. In 
the Ingenic DT files, by the way, you don't see so much of this any more 
because the groups are actually defined in the driver itself.)

And then, there would be something using this pin group. Here, I have to guess 
which phandle to use amongst other things. Since tcon0 is an A20 thing, this 
would be in the computer card DT, with other card DTs providing their own 
necessary recipes:

&tcon0 {
	ports {
   		tcon0_lcd_out: port at 2 {
			...
			tcon0_out_lcd: endpoint at 2 {
				...
				remote-endpoint = <&vga_connector_in>;
			};
		};
	};
};

Here, I'm missing the mechanism by which the pin group gets selected. Some 
kind of coordination with the driver would be needed, I guess. Otherwise, it 
wouldn't know which mode to use so as to produce output on the LCD0 pins.

> > Normally, there would be a connector node with an endpoint, so something
> > like this in the housing DT, perhaps:
> > 
> > vga0: connector at 0 {
> > 
> >         compatible = "vga-connector";
> >         label = "vga";
> >         
> >         port {
> >         
> >                 vga_connector_in: endpoint {
> >                 
> >                         remote-endpoint = <&vga_out>;
> >                 
> >                 };
> >         
> >         };
> > 
> > };
> 
> this definition would go in the *Housing* dtb fragment.

Yes, in the housing DT.

> the vga_out is defined to contain *dynamic*  connections which link HSYNC
> to eoma68-pin33 (whatever).
> 
> only when the "dynamic merge" kernel syscall is made will the substitutions
> occur, *including* the (now new) definition of vga0 events will then fire,
> the associated rgbttl.ko gets loaded, and (eventually) /dev/fb0 appears.

Yes, I'm just missing some idea of the actual device tree plumbing. But then I 
don't think I'm particularly good at figuring out Linux device drivers and 
device trees.

Paul