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

[Luke Kenneth Casson Leighton]

On Monday, July 20, 2020, Paul Boddie <paul at 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
>
>
>

-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68