Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#900799: linux-image-arm64: dts: rockchip: correct voltage selector Firefly-RK3399

39 views
Skip to first unread message

Heinrich Schuchardt

unread,
Jun 5, 2018, 1:40:03 AM6/5/18
to
Package: linux-image-arm64
Version: 4.16.12-1
Severity: normal
Tags: patch

Please, add this patch to the Debian kernel patches until it is added
upstream. Cf.
https://lkml.org/lkml/2018/6/4/781

Without this patch the Firefly-RK3399 board boot process hangs after these
lines:

fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
fan53555-reg: supplied by vcc_sys
vcc1v8_s3: supplied by vcc_1v8

Blacklisting driver fan53555 allows booting.

The device tree uses a value of fcs,suspend-voltage-selector different to
any other board.

Changing this setting to the usual value is sufficient to enable booting.

Signed-off-by: Heinrich Schuchardt <xypro...@gmx.de>
---
arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
index 4f28628aa091..50940ef844a7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -458,7 +458,7 @@
vdd_cpu_b: regulator@40 {
compatible = "silergy,syr827";
reg = <0x40>;
- fcs,suspend-voltage-selector = <0>;
+ fcs,suspend-voltage-selector = <1>;
regulator-name = "vdd_cpu_b";
regulator-min-microvolt = <712500>;
regulator-max-microvolt = <1500000>;
--
2.17.1

Heinrich Schuchardt

unread,
Jun 14, 2018, 3:40:02 PM6/14/18
to
The patch has been accepted by the upstream maintainer.

https://lkml.org/lkml/2018/6/14/365


-------- Forwarded Message --------

applied for 4.19.

I've amended your commit message with the info from your reply about
the vendor kernel using the same value and added an appropriate Fixes
tag to possibly get it merged into stable.


Thanks
Heiko

Diederik de Haas

unread,
Jun 1, 2022, 5:40:04 AM6/1/22
to
On Fri, 22 Jun 2018 21:58:30 +0100 Ben Hutchings <b...@decadent.org.uk> wrote:
> Version: 4.17.2-1~exp1
>
> On 5 Jun 2018 07:33:11 +0200 Heinrich Schuchardt <xypro...@gmx.de> wrote:
> > Please, add this patch to the Debian kernel patches until it is added
> > upstream. Cf.
> > https://lkml.org/lkml/2018/6/4/781
>
> This was applied in the above merge but not mentioned in the changelog
> due to a mis-merge.

In response Heiko says in https://lkml.org/lkml/2018/6/19/1167:
"and dropped again.

Sadly it looks like the patch causes conflicts with at least one firefly
board in a kernelci lab. My own is currently not ready to use, so I cannot
look myself right now.

The issue kernelci people described sounded quite a lot like the one
in your commit message, so my current theory is that the
suspend-voltage-selector must in some form corespond to the
cpu_b_sleep_h gpio setting we're currently not handling at all, which
would therefore depend on how the bootloader sets this up."

It's also not part of current upstream master, so this is a DTS change that is
specific for Debian and possibly not needed and/or incorrect?

Heinrich, can you tell us more about the current status of this patch?
signature.asc

Heinrich Schuchardt

unread,
Jun 1, 2022, 1:10:04 PM6/1/22
to
I have not been working on the board in the last years.

My impression at the time was that one would have to detect the current
state of the board at runtime which matches what you wrote.

Best regards

Heinrich

Diederik de Haas

unread,
Jun 1, 2022, 3:30:08 PM6/1/22
to
Thanks for your response.
FTR: It was all part of Heiko's quote; I have no insight in this matter.

Normally, AIUI, patches like these are added in expectation that they can be
dropped later when it's merged into upstream source code.
As that did not happen in this case I think it would be better to just drop
this patch from the Debian kernel.

It may be that upstream has fixed this issue in another way (I have no idea
whether this is the case). And if the issue resurfaces again (against a
current kernel), then we can see whether this patch would fix it (again) and
then we'd have a better case to actually get it integrated in the upstream
source.

But that's a decision that one of the Debian kernel maintainers should make.

Cheers,
Diederik
signature.asc
0 new messages