Hello Robin,
On 2019/03/27 0:43, Robin Murphy wrote:
On 26/03/2019 14:29, Katsuhiro Suzuki wrote:
Hello Heiko, Robin,
Thank you for your suggestion. Yes, I found &io_domains{} node in
device tree too. I'm temporary fixing this problem by patch like as
Robin's suggestion.
But I'm confusing that RockPro64 schematics (Power Domain Map) says
default voltage of audio_gpio3d_gpio4a is 1.8V and gpio1830_gpio4cd is
3.0V. It shows that current setting of device tree is correct.
Oh, I hadn't spotted that, I just looked at p16 where it shows APIO5_VDD
supplied by VCC_3V0. I would assume that that power domain map page
simply never got updated when the actual RockPro64 design was changed
away from the Rockchip reference schematic.
Thanks, I agree with you. Power Domain Map is staying old or something
wrong... I will send patch to fix APIO5 domain voltage.
Best Regards,
Katsuhiro Suzuki
Robin.
I don't understand why other person who is using linux-next does not
face this problem...??
Best Regards,
Katsuhiro Suzuki
On 2019/03/26 22:58, Robin Murphy wrote:
On 26/03/2019 13:51, Heiko Stübner wrote:
Hi,
Am Dienstag, 26. März 2019, 14:39:42 CET schrieb Katsuhiro Suzuki:
Hello Tony, Robin,
I continue to investigate UART TX rising time problem. Recently, I
found
one of cause of this problem.
In my environment, this problem occurred on linux-next only. U-Boot
does
not face it. So I compared settings between U-Boot and linux-next.
After
I found GRF_IO_VSEL (address 0xff77e640) register is differ.
Would you tell me what value is stored into this register?
My RockPro64, initially 0x00000000 is set but 0x00000003 is set during
linux boot. UART TX rising time becomes fine if set both bit 1 and
bit 3
or clear both bits.
GRF_IO_VSEL is the voltage-domain selection for different domains,
see the &io_domains{} node in your rockpro64 dts.
The soc needs to know with what voltage some of its inputs are
supplied.
Bits are:
0 - bt656
1 - audio
2 - sdmmc
3 - gpio1833
These bits must correspond of the voltages of their regulators,
0 for 3.3V and 1 for 1.8V.
But the vcc1v8_dvp regulator connected to the bt656 input has
not changed since the initial submission of the devicetree.
Hmm, based on a look through the rockpro64 schematic, does this help?
Robin.
----->8-----
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
index 1f2394e0587d..d473ce290f0c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
@@ -504,7 +504,7 @@
status = "okay";
bt656-supply = <&vcc1v8_dvp>;
- audio-supply = <&vcca1v8_codec>;
+ audio-supply = <&vcc_3v0>;
sdmmc-supply = <&vcc_sdio>;
gpio1830-supply = <&vcc_3v0>;
};
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
