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

[Luke Kenneth Casson Leighton]

On Tue, Jul 21, 2020 at 11:53 PM Paul Boddie <paul at boddie.org.uk> wrote:
>
> On Tuesday, 21 July 2020 23:25:12 CEST Luke Kenneth Casson Leighton wrote:
> > On Tue, Jul 21, 2020 at 9:57 PM Paul Boddie <paul at boddie.org.uk> wrote:
> > > OK, so the housing DT will contain the following for a VGA port...
> >
> > paul: quite late, here, more tomorrow.  summary strategy:
> >
> > * look at rbpi "hats" and how dtb overlays are done
> > * copy that
> > * rename rbpi "hat" overlay pins 0 to M to "eoma68 pins 1 to 68"
>
> It would be useful to know where all these "hats" are defined. I found the
> following:
>
> https://github.com/raspberrypi/linux/tree/rpi-5.4.y/arch/arm/boot/dts/overlays

https://github.com/raspberrypi/linux/blob/rpi-5.4.y/arch/arm/boot/dts/overlays/gpio-ir-overlay.dts

they're merging the pull-up and setup functionality with the actual
device itself.  this completely defeats the object of the exercise.


> > that really should be all.
>
> Sorry, I just don't see how the overlays I found do this generically.

if that IR example is anything to go by.

> That works just fine with things like Raspberry Pi, but what we really need to
> see is what a device tree overlay looks like for a product that is used on
> multiple devices without needing to be customised for each one, if such an
> overlay exists.
>
> The only thing I've found that seems to do pin aliasing is this:
>
> https://beagleboard.org/blog/2018-01-17-building-a-device-tree-overlay-for-your-new-pocketcape-design

yes, pin aliasing should do the trick.  so instead of (as in the IR example)

                                brcm,pins = <18>;
 // pin 18
                                brcm,function = <0>;                    // in
                                brcm,pull = <2>;                        // up

it would be

                                eoma68,pins = <18>;
   // pin 18
                                eoma68,function = <0>;                    // in
                                eoma68,pull = <2>;                        // up


> Even then, there is some pretty liberal usage of what appear to be device-
> specific node references alongside the pin aliases, but I guess it is a start.

indeed.

so what it looks like is, the beagleboard example shows how to
"disable" pins (describes it as "get them back").  following that, if
those pins can be cut/paste redefined and given eoma68 names, i
believe we're good to go.

i believe it may be necessary to have two definitions for each pin,
though (in each Card Overlay).

* one definition for the EOMA68 pin as a GPIO
* one definition for the EOMA68 pin in its "function" capacity.  SPI
MOSI for example.

the "hats" then choose which of these to "group together" in order to
create "EOMA68 SPI" or "EOMA68 LCD 15 pin bus" and so on.

l.