On 04/07/2015 12:59 PM, Javier Martinez Canillas wrote: > > So IIUC the CG_STATUS0 bits were a red herring and the real problem > is that the aclk266_g2d needs to be enabled during suspend (although > we still don't know why). > > It seems were are at a dead end now. Without being able to ask the HW > Samsung folks we would never know what's going on here... > Ok, I found another interesting data point. ACLK_266_G2D has as constraints that CG_STATUS0[21:22] needs to be 0 before gating the clock and as I mentioned before those are associated with the SSS and SSS_SLIM HW crypto modules according the docs I've. So I looked at the clock used by the SSS module and found that CLK_SSS parent is ACLK_266_G2D but CLK_SSS is never requested since drivers/crypto/s5p-sss.c isn't built for exynos_defconfig. Enabling CONFIG_CRYPTO_DEV_S5P makes the system to resume without any patches since the sss clock prevents aclk266_g2d to be gated. But I wanted to know if it was really aclk266_g2d that was needed or the actual sss clock since the kernel didn't manage that clock without the driver enabled. So I disabled the sss clock before trying a S2R: # devmem 0x10018800 32 0xFFFFFFFB (CLK_SSS in CLK_GATE_IP_G2D is gated) and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to its default value on S2R so maybe that is why it works anyways? # devmem 0x10018800 0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS) Does this shed any more light? Could the problem be that the sss clock parent (aclk266_g2d) is gated during S2R? Is the SSS module required for S2R or is just that CLK_SSS prevents the parent to be gated and so it is another red herring? Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |