* Adam Ford [off-list ref] [190814 19:14]:

echo on > /sys/bus/platform/devices/5000fe00.target-module/power/control
# devmem 0x5000fe00 32
0x40000000

and

echo auto > /sys/bus/platform/devices/5000fe00.target-module/power/control
# devmem 0x5000fe00 32
[  776.373504] 8<--- cut here ---
[  776.376617] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6
f76e00
[  776.384338] pgd = bde98bb0
[  776.387054] [b6f76e00] *pgd=8cb61831, *pte=5000f383, *ppte=5000fa33
[  776.393402] In-band Error seen by MPU  at address 0

Then

Tested-by: Adam Ford <redacted> #logicpd-torpedo-37xx-devkit

Thanks for testing, yes that's all there is to it for the SoC glue in
this case. The child device driver(s) can be just generic sgx driver(s)
that just do pm_runtime_get_sync() to access the registers and that
enables the parent interconnect target module as needed.

I do wonder if an omap34xx or omap36xx should use
compatible = "ti,sysc-omap4", "ti,sysc";

should it use an omap3 equivalent?

We named the old hwmod type1 as ti,sysc-omap2, type2 as ti,sysc-omap4,
and type3 as ti,sysc-omap4-simple based on where we thought they
appeared. Based on the sysconfig register bit layout, sgx on omap36xx
seems to have a subset of ti,sysc-omap4 and we can recycle it. If we
used a wrong type, the module would not get enabled or disabled as
the register bits would not match.

How about let's add a comment like:

Yes sg has a subset of ti,sysc-omap4 type sysconfig register

Regards,

Tony