Re: PM / devfreq: exynos-bus: need for suspend OPP?

[Tobias Jakobi <tjakobi@math.uni-bielefeld.de>]

Hi MyungJoo,

MyungJoo Ham wrote:
> On Mon, Nov 21, 2016 at 11:48 PM, Markus Reichl <m.reichl@fivetechno.de> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>