Asus Transformers fixes

[maximschwalm]

• Fix booting from recovery
• Fix RT5631 registers being out of sync after resuming from suspend
• Fix backlight supply
• Add some missing supplies
• Reduce W1 ramp delay to 20ms
• Choose better regulator names

[digetx]

Doesn't this result in a error from MMC core when it tries to set 3.3v mode? I think this should stay 3.3v.

[maximschwalm]

I don't think that 3.3v will be used. The kernel tries to match the vmmc and vqmmc voltage. That's why I can't set vqmmc lower than what vmmc is set to, because then the kernel complains that the voltage would be out of range

[digetx]

What change fixed panel after rebooting?

[maximschwalm]

What change fixed panel after rebooting?

Removing the ramp delay from the panel regulator

[digetx]

Do you have any idea why ramp delay causes the problem?

[maximschwalm]

Do you have any idea why ramp delay causes the problem?

I don't have any explanation. I discovered this purely by trial and error

[digetx]

The original downstream kernel seems use 20ms delay, could you please check whether it works?

https://github.com/clamor-s/morpheus_kernel_asus_tf201/blob/asus/arch/arm/mach-tegra/board-cardhu-panel.c#L315

-		regulator-enable-ramp-delay = <300000>;
+		regulator-enable-ramp-delay = <20000>;

[maximschwalm]

The original downstream kernel seems use 20ms delay, could you please check whether it works?

https://github.com/clamor-s/morpheus_kernel_asus_tf201/blob/asus/arch/arm/mach-tegra/board-cardhu-panel.c#L315

-		regulator-enable-ramp-delay = <300000>;
+		regulator-enable-ramp-delay = <20000>;

Shouldn't startup-delay-us be used when the regulator is fixed?

[digetx]

Looks like both should work equally. I don't know why startup-delay-us exists, maybe it's a legacy property.

[maximschwalm]

No, it doesn't work. Same issue again

[digetx]

Can you try a lower delay? Like 1ms.

[clamor-s]

@digetx may you halt this PR till 9th of June. I would really like to review them as well. I'm currently out of home network with poot wifi.

[digetx]

We can wait. I want to know why regulator delay makes a difference, this is the biggest question for me here.

[maximschwalm]

After further testing it seems like removing the ramp delay didn't fix it at all. It was probably just a coincidence that the display worked after reboot, but I could reboot several times in row and it was still working.

[okias]

...but I could reboot several times in row and it was still working.

maybe you set something before and it's not (properly) initialized by kernel?

[digetx]

@maximschwalm could you please check reboot with this change?

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index a46f86d2fea5..5bbf5132dc41 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -4954,7 +4954,7 @@ static struct mipi_dsi_driver panel_simple_dsi_driver = {
 	},
 	.probe = panel_simple_dsi_probe,
 	.remove = panel_simple_dsi_remove,
-	.shutdown = panel_simple_dsi_shutdown,
+// 	.shutdown = panel_simple_dsi_shutdown,
 };
 
 static int __init panel_simple_init(void)

[maximschwalm]

@maximschwalm could you please check reboot with this change?

Thanks, so it worked better, but after the 5th try it failed again. What seems to be different is, that it can work again after another reboot. Previously I had to completely switch off the device

[digetx]

It may lead to the root of the problem, but it's not a fix yet. Could be that the W1 gpio needs to be enabled for the TC bridge, have you checked it?

diff --git a/arch/arm/boot/dts/tegra30-asus-tf700t.dts b/arch/arm/boot/dts/tegra30-asus-tf700t.dts
index 1dec83d07555..bec5056efb66 100644
--- a/arch/arm/boot/dts/tegra30-asus-tf700t.dts
+++ b/arch/arm/boot/dts/tegra30-asus-tf700t.dts
@@ -157,7 +157,6 @@ display-panel@1 {
 				compatible = "panasonic,vvx10f004b00";
 				reg = <1>;
 
-				power-supply = <&vdd_pnl>;
 				backlight = <&backlight>;
 
 				port {
@@ -231,7 +230,7 @@ vdd_1v2_mipi: regulator@6 {
 		regulator-boot-on;
 		gpio = <&gpio TEGRA_GPIO(BB, 3) GPIO_ACTIVE_HIGH>;
 		enable-active-high;
-		vin-supply = <&vdd_3v3_sys>;
+		vin-supply = <&vdd_pnl>;
 	};
 
 	vibrator {

We shouldn't remove the W1 ramp delay (maybe change it to 20msec) and should be better not to change the limits of those regulators where we not sure yet. Could you please update this PR?

[maximschwalm]

It may lead to the root of the problem, but it's not a fix yet. Could be that the W1 gpio needs to be enabled for the TC bridge, have you checked it?

Not yet. Should I try it without the previous patch?

[digetx]

Yes, without the previous patch.

[digetx]

The reboot problem is unrelated to the rest of the changes in this PR, it shouldn't block fixing the MMC regulators.

[maximschwalm]

Yes, without the previous patch.

This time it fails sooner and doesn't get fixed by another reboot

[digetx]

Now you can narrow down the panel_simple_dsi_shutdown() to the point that breaks display after reboot. Once we will know that point, we will think about how to fix it.

The updated PR looks good to me. I'll merge it, thanks!