OK, I don't think this is as easy implementable as MyungJoo implied.
- exynos_bus_suspend() and exynos_bus_resume() are not called during
shutdown/reboot.
- devfreq_suspend_device() and devfreq_resume_device() have to be called
from driver code.
- I tried to put a reset notifier block in place, like it is done in the
eMMC pwrseq code, but the kernel just hangs there for a reason. Maybe
using RCU at this point doesn't work anymore. Also the notifier block
would not help for suspend.
And adding something like cpufreq_{suspend,resume}() for devfreq seems
quite invasive. And probably something I lack the skills for.
- Tobias
MyungJoo Ham wrote:
> On Tue, Nov 22, 2016 at 12:23 AM, Tobias Jakobi
> <tjakobi@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> 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?
>
> Yes, that's correct.
>
>>
>> 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?
>
> Yes, that's because PMIC is a physically separated component, connected
> via an external (out of SoC) bus; I2C and IRQ lines, which is the root of the
> inconsistency after resume with old BL0. (I think I remember that recent
> BL0 do remember the status after resume)
>
> Usually such instability is caused by setting the voltage of PMIC low
> (because the freq was low) while the default frequency (freq at
> boot-up) of SoC is higher.
>
>
> Cheers,
> MyungJoo
>
>>
>>
>>> 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
