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

[Paul Boddie]

On Tuesday, 21 July 2020 00:49:48 CEST Luke Kenneth Casson Leighton wrote:
> 
> i would prefer a level of indirection that names the EOMA68 pins by
> numbers, these numbers to be nothing to do with the function
> 
> the reason being that exactly like pinctrl all EOMA68 Interface pins
> (except USB) can be GPIO.
> 
> then, just like pinctrl, the next layer drops overlays onto those 68 pins
> to provide LCD ... *if the Housing  Manufacturer wants them to be LCD*.

OK, so the housing DT will contain the following for a VGA port...

An actual connector definition for the benefit of various mechanisms. The 
reason why I keep mentioning this is because the DRM mechanisms seem to depend 
on it: there needs to be some kind of sink for the signal, and it's usually 
some kind of connector. But this is arguably the easy part.

Something that indicates the EOMA pin requirements to supply that connector. 
Normally, pin usage gets written on a specialisation of a device peripheral. 
For example, for the Ben NanoNote:

&lcd {
        pinctrl-names = "default";
        pinctrl-0 = <&pins_lcd>;

        port {
                panel_output: endpoint {
                        remote-endpoint = <&panel_input>;
                };
        };
};

But in the EOMA68 universe, we don't want to override a specific peripheral 
(&lcd here refers to the LCD controller on the JZ4720), nor do we want to 
indicate pins that are SoC-specific.

So, we can define some kind of mapping for pins in the computer card DT, just 
as you do here...

> these examples shows that it is therefore quite important to not drop
> functions directly onto pins but to have that "redirection" layer:
> 
> &pio {
>         eoma68_pin0:  {
>                 pins = "PD0"
>                 function = "eoma68-pin0";
>         };
>         eoma68_pin1:  {
>                 pins = "PE5"
>                 function = "eoma68-pin1";
>         };
>         .....
>         .....
> };
> 
> and *then* have an LCD dtb overlay (one 24, one 18, one 16 and one 15)
> which refers to the pins by their *EOMA68* name
> 
> NOT the pinctrl name (e.g. from sunxi a20 dts) which is SoC specific.

But what I am missing is the construct by which you might apply the pin 
reservations, unless you are merely making aliases for platform-specific pin 
names within pinctrl and then using those in places where pinctrl attributes 
are used.

Specifically, what I wonder about is how the equivalent of the <&pins_lcd> 
gets applied at the SoC level given some kind of (platform-neutral) pin 
reservation in the housing DT.

Sorry if this is obvious, but without concrete DT syntax for the configuration 
throughout the different layers, I cannot see exactly how this would be done.

Paul

P.S. But recent experiences may be colouring my judgement here, having been 
trying to shake the box of existing drivers and DT fragments to try and 
persuade my CI20 to produce HDMI output, so far unsuccessfully. And yet, 
practically the same code produces a picture just fine when ported to L4Re, 
without all the distractions of driver frameworks and device trees (and the 
DRM stack testing modes over and over and over again).