All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kukjin Kim <kgene@kernel.org>,
	linux-samsung-soc@vger.kernel.org,
	Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Subject: Re: [PATCH] ARM: dts: exynos4412-odroid-*: add workaround for CPUfreq/reboot issue
Date: Wed, 02 Sep 2015 11:00:09 +0900	[thread overview]
Message-ID: <55E65829.3050200@samsung.com> (raw)
In-Reply-To: <15844858.D7Muz8OFGX@amdc1976>

On 01.09.2015 23:08, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Tuesday, September 01, 2015 10:57:37 PM Krzysztof Kozlowski wrote:
>> 2015-09-01 22:08 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
>>> Exynos4412-based Odroid boards (X2, U3, U3+) don't reset PMIC
>>> configuration during hardware reset. This causes serious issues with
>>> CPUfreq, when ARM voltage is set below 1.0V. When one resets the board
>>> when CPUfreq selected one of lower Exynos 4412 operating points (for
>>> example: 200MHz and 0.9V), the bootloader crashes and it is not possible
>>
>> s/crashes/hangs/ ? I did not observe a crash but a silent hang.
>>
>>> to restart the board without turning power off.
>>>
>>> This patch provides a workaround for this issue by increasing the start
>>> of valid range for vdd_arm regulator from 1.0V. After such change,
>>> CPUfreq can still use lower operating points, but the voltage won't be
>>> decreased below 1.0V and as a result it will be possible to reset board
>>> at any time.
>>>
>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
>> Do you plan to send the same fix for Trats2 board? Everything above
>> applies there as well plus suspend is affected. The board cannot
>> properly resume.
>>
>>> ---
>>> Hello,
>>>
>>> This issue was there from the beggining, but I was not able to reproduce
>>> it. It has been already reported by Tobias in early Feb 2015
>>> (http://www.spinics.net/lists/linux-samsung-soc/msg42294.html).
>>> Recently, after CPUfreq changes (conversion to generic cpufreq dt and
>>> enabling cpufreq in exynos_defconfig) it was much easier to observe this
>>> issue.
>>>
>>> This workaround lets one still use CPUfreq and avoid unexpect board
>>> crashes during reboot (both 'standard' and emergency).
>>
>> Work-around looks nice and clean. It still allows to use cpufreq and
>> reduce the energy consumption. The patch should go along with
>> cpufreq-dt support for Exynos4412 which hopefully would be for v4.3.
>> If cpufreq-dt for Exynos4412 won't get to v4.3 we can figure out
>> proper solution, not a work-around.
> 
> This work-around is needed also for the old exynos-cpufreq driver
> as the problem was already there on some Odroid setups (please read
> the mail from February pointed by Marek for details).

This probably would mean that this should go to stable as well but was
not marked as such. Any reason against backporting?


BTW, on old driver it seems that Trats2 is not affected. Both suspend
and reboot works.

Best regards,
Krzysztof

> 
> We don't have a better fix for the time being so I think that it
> should be merged now regardless of cpufreq-dt changes status.
> 
>> Anyway for the time being:
>> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>
>> Thanks Marek,
>> BR
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
> 
> 

      reply	other threads:[~2015-09-02  2:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-01 13:08 [PATCH] ARM: dts: exynos4412-odroid-*: add workaround for CPUfreq/reboot issue Marek Szyprowski
2015-09-01 13:57 ` Krzysztof Kozlowski
2015-09-01 14:08   ` Bartlomiej Zolnierkiewicz
2015-09-02  2:00     ` Krzysztof Kozlowski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55E65829.3050200@samsung.com \
    --to=k.kozlowski@samsung.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=kgene@kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=tjakobi@math.uni-bielefeld.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.