Hi MyungJoo, MyungJoo Ham wrote: > On Mon, Nov 21, 2016 at 11:48 PM, Markus Reichl <m.reichl@xxxxxxxxxxxxx> wrote: >> Hi Tobias, >> >> Am 21.11.2016 um 14:33 schrieb Tobias Jakobi: >>> Hello everyone, >>> >>> I was thinking about the following. At the moment we have a suspend OPP >>> for cpufreq-dt in place for the Exynos4412 SoC (added in >>> 1605b60ad064c7019db8ade07f0b7bdc8c197b93). The rationale behind is that >>> the board using the SoC might not have some PMIC reset in place. In case >>> the board goes into reboot with a low OPP (i.e. low frequency, but also >>> low core voltage), this results in a hang when the first-stage >>> bootloaders sets its default core frequency. >>> >>> So this is properly handled in the kernel just fine, except for some >>> corner cases like emergency reboot. >>> >>> But some time ago devfreq support for the various busses in the >>> Exynos4412 was added. On the ODROID boards e.g. this adjust MIF and INT >>> voltage. >>> >>> Let us take the DMC bus. Operating frequency is 100~400MHz and voltage >>> is 900~1050mV. >>> >>> Now let's look at the corresponding board file >>> (http://git.denx.de/?p=u-boot.git;a=blob;f=board/samsung/odroid/odroid.c#l234) >>> in upstream u-boot. If I read this correctly DMC is set to 400MHz there. >>> >>> Here's the question. Could this, similar to the cpufreq/core frequency >>> issue, pose a problem when the kernel goes into reboot when DMC is on >>> the lowest OPP state? >>> >>> I'm not saying that it does. This just came to my mind during some >>> recent discussion. >> >> Made a test with >> # echo performance > /sys/class/devfreq/bus_leftbus/governor >> # echo performance > /sys/class/devfreq/bus_dmc/governor >> just before reboot. >> >> 20 out of 20 reboots worked. >> >> With devfreq simple_ondemand governor around 50% reboots hung. >> >> This could support your thoughts above. >> >> Servus, >> -- >> Markus > > Either in each device driver (just implemented in the suspend/resume callback) > or in subsystem code, we may need to handle the inconsistency after resume. by device driver code you mean exynos-bus, i.e. drivers/devfreq/exynos-bus.c? In the subsystem code (I assume you mean drivers/devfreq/devfreq.c here) I see devfreq_{suspend,resume}_device(). I'm not sure though if these are called at the correct times. Need to check this. > This is normally because the BL0 bootloader of the CPU simply resets the values > at wake-up. I think recent Exynos series don't do that anymore, but > 4412 might be > the one before such improvement. So just to make sure. The BL0 resets the clocks to default values, but leaves the regulators / PMIC alone? > You may make it stable by first implementing suspend/resume callback > correctly for them. > > Adding such feature at devfreq subsystem isn't bad as long as it incurs > minimal changes (no new extern functions are required for that) > and does not affect those who do not need it or shouldn't do it. > (recent attempts were not satisfying those criteria) Well, I'm not sure if I'm up to the task. I guess I'll give it a try. Thanks for the info! - Tobias > Cheers, > MyungJoo > -- > 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 > -- 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
 |