* Adam Ford <aford173@xxxxxxxxx> [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@xxxxxxxxx> #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
