On Monday, July 20, 2020, Paul Boddie paul@boddie.org.uk wrote:
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...
if we follow the idea put forward by the rbpi "hat" community, actually "VGA peripheral" or "SPI Ethernet peripheral" would be yet further separatw dtb fragments (overlays) that get dropped on top of a "Housing" overlay.
even the EOMA68 SDMMC interface could potentially have a "hat" file for a SD WIFI Card or other type of non-dynamically-detectable peripheral.
it gets complicated, pretty quickly, but this is kinda unavoidable.
part of my responsibility as the Cerification Mark holder is to maintain that database of overlay fragments and ensure that it is properly compliant and well documented.
[...]
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.
the overlays *use* those pinctrl groups and basically limit them to a hard subset of functionality.
so for example, one set of pins routed to EOMA68 I2C *might* also be capable of supporting UART by a happy coincidence.
however despite this being possible it is NOT permitted to advertise that fact... and also claim EOMA68 Compliance.
to protect users who expect interoperability now and in 20 years time i have to drop a ton of bricks on anyone trying to say "oh yes, EOMA68 devices can do UART on the I2C pins" for example.
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"; }; };
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*.
if the Housing Manufacturer wants 15 pin RGBTTL not 24 pin RGBTTL that frees up quite a few pins in the EOMA68 RGBTTL bank for use as GPIO.
likewise SDMMC can operate in 1 pin mode, freeing up 3 other pins for GPIO.
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.
Here, I'm missing the mechanism by which the pin group gets selected.
the abstraction / indirection, explicitly naming the pins with EOMA68 pin names, i believe answers this.
Cards dtb files *provide* those 68 pins as named in the dtb file
Housing overlays *use* those 68 names.
Engineers using rbpi style Housings (such as the Microdesktop with its 20 pin header) drop "hat" overlays onto functions such as eoma68_spi or eoma68_i2c and so on.
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.
correct. this is what the I2C EEPROM is for.
it is the responsibility of uboot and the linux kernel to:
* read the EEPROM * determine the Housing type * load the correct dtb overlay
at that point the Card can automatically recognise the Housing, drivers load from there and users are happy. "Plug it in, it will just work" is satisfied.
of course, this means they need to regularly keep the dtb overlay database updated...
.
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
it's all there. the pieces are in place. reading the I2C EEPROM however does need to be written.
alan cox suggested this be added to lib/eoma68 in the linux kernel source tree.
l.
Paul