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

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

[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.


With best wishes,
Tobias

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

[Markus Reichl]

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
> 
> 
> With best wishes,
> Tobias
> --
> 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
> 

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

[MyungJoo Ham]

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.

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.

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)



Cheers,
MyungJoo

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

[Tobias Jakobi]

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
> 

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

[MyungJoo Ham]

On Tue, Nov 22, 2016 at 12:23 AM, Tobias Jakobi
<tjakobi@math.uni-bielefeld.de> wrote:
> 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?

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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>



-- 
MyungJoo Ham, Ph.D.
S/W R&D Center, Samsung Electronics

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

[Tobias Jakobi]

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@math.uni-bielefeld.de> wrote:
>> 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?
> 
> 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@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> 
> 
> 

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

[MyungJoo Ham]

On Tue, Nov 22, 2016 at 7:15 AM, Tobias Jakobi
<tjakobi@math.uni-bielefeld.de> wrote:
> 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.

You don't need them at shutdown/reboot. probe() is going to be called
afterwards anyway.

>
> - devfreq_suspend_device() and devfreq_resume_device() have to be called
> from driver code.

Yes. That's the limitation.

The easiest way is to fix the freq/volt at device driver.

Unless devfreq manages struct device directly at subsystem, it won't
be easy to manage device's suspend/resume directly.


MyungJoo

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

[Tobias Jakobi]

Hello again,

I've just send a draft for the patch(set) I have in mind.

It's still in bad shape and I would appreciate some comments from the
guys more versed with the DevFreq subsystem than me. In particular I'm
not sure how exactly the various components (exynos-bus, devfreq,
devfreq-event, governor) work together.

- Tobias

MyungJoo Ham wrote:
> On Tue, Nov 22, 2016 at 7:15 AM, Tobias Jakobi
> <tjakobi@math.uni-bielefeld.de> wrote:
>> 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.
> 
> You don't need them at shutdown/reboot. probe() is going to be called
> afterwards anyway.
> 
>>
>> - devfreq_suspend_device() and devfreq_resume_device() have to be called
>> from driver code.
> 
> Yes. That's the limitation.
> 
> The easiest way is to fix the freq/volt at device driver.
> 
> Unless devfreq manages struct device directly at subsystem, it won't
> be easy to manage device's suspend/resume directly.
> 
> 
> 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
> 

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

[Tobias Jakobi]

Hello Markus,


Markus Reichl 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.
thanks for the tests. I assume by 'reboots hung' you mean that the boot
process doesn't even reach u-boot?

- Tobias


> This could support your thoughts above.
> 
> Servus,
> --
> Markus
>>
>>
>> With best wishes,
>> Tobias
>> --
>> 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
>>
> --
> 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
> 

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

[Markus Reichl]

Hi Tobias,

Am Montag, 21. November 2016, 16:16:24 schrieb Tobias Jakobi:
> Hello Markus,
> 
> 
> Markus Reichl 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.
> thanks for the tests. I assume by 'reboots hung' you mean that the boot
> process doesn't even reach u-boot?

Yes, in these cases u-boot does not appear on the U3.

--
Markus
> 
> - Tobias
> 
> 
> > This could support your thoughts above.
> > 
> > Servus,
> > --
> > Markus
> >>
> >>
> >> With best wishes,
> >> Tobias