Re: [PATCH 0/6] Configure sgx interconnect data for some omap variants

[Tony Lindgren <tony@atomide.com>]

* Adam Ford <aford173@gmail.com> [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 <aford173@gmail.com> #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