Hi, On Monday, April 07, 2014 09:28:39 AM Olof Johansson wrote: > On Fri, Apr 4, 2014 at 9:09 AM, Bartlomiej Zolnierkiewicz > <b.zolnierkie@xxxxxxxxxxx> wrote: > > [...] > > I know that this is mainly our problem but the issue is widespread on > > our targets and I believe that adding some workaround for it in cpuidle > > core would be beneficial for the whole cpuidle subsystem. On the second look at the cpuidle code there is a "cpuidle.off" kernel parameter which should be sufficient to workaround this particular issue for now. > Yes, we need to find a way forward without you guys holding the whole > platform hostage with out-of-tree code (here and in general, since I > think there are more areas in which this applies). Please explain this more because I really don't know what you're meaning here (at least in case of SRPOL I feel that there are no such issues). In this particular case we have a problem with a modified uboot bootloader versions being broken and incompatible with the advanced AFTR cpuidle mode. This is not the only / main issue preventing AFTR mode and thus EXYNOS cpuidle driver from being used by default so I really think that the your comment was unfair. > > Namely there > > should be some way of telling cpuidle subsystem to either disable > > particular state(s) or limit the max available state. I think that this > > can be also useful for testing and development of other cpuidle drivers. > > > > For now please change this patch to add CONFIG_CPU_IDLE=n instead (since > > the config option is "default y" it will be auto-enabled if there is no > > entry in the defconfig).. > > Can the code be refactored such that even if CPU_IDLE is on, it won't > actually do anything useful on the platforms that have problems above? > I.e. determined at runtime, not build time? We can disable AFTR mode by default on EXYNOS4x12 SoCs with secure mode enabled and EXYNOS5420 SoCs (I would like somebody with the hardware to verify that AFTR mode is not working first so we have 100% certainty that we don't regress here). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- 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
 |