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).