Hi,
On Fri, Dec 10, 2021 at 08:18:35PM +0100, Merlijn Wajer wrote:
> Hi Sebastian,
>
> I don't know if this is something that requires any action currently,
> but I wanted to report that I'm seeing some increased power draw on a
> Nokia N900 with minimal userspace on Linux 5.10 (and the same happens on
> 5.15 it seems, so it doesn't seem to be resolved since). I tried to
> bisect the problem but my initial attempt failed, because the problem
> seems a bit racy or unpredictable.
>
> Basically I boot a system to init=/bin/bash and run the following:
>
> > modprobe panel-sony-acx565akm
> >
> > mount -t proc none /proc
> > mount -t sysfs none /sys
> > mount -t debugfs none /sys/kernel/debug
> > mount -o rw,remount /
> >
> > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode
> > echo 0 > /sys/class/backlight/acx565akm/brightness
> >
> >
> > consoles=$(find /sys/bus/platform/devices/4*.serial/ -name console)
> > for console in ${consoles}; do
> > echo N > ${console}
> > done
> >
> > # Enable autosuspend
> > uarts=$(find /sys/bus/platform/devices/4*.serial/power/ -type d)
> > for uart in ${uarts}; do
> > echo 2000 > ${uart}/autosuspend_delay_ms
> > echo enabled > ${uart}/wakeup
> > echo auto > ${uart}/control
> > done
> >
> > # Configure wake-up from suspend
> > uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d)
> > for uart in ${uarts}; do
> > echo enabled > ${uart}/wakeup
> > done
>
> This loads the panel and then sets the brightness to zero, enables off
> mode and idles the kernel console/serial.
>
> Then run the following to check idle states:
>
> grep ^core_pwrdm /sys/kernel/debug/pm_debug/count | cut -d',' -f2,3
>
> And also check the power usage on lab power supply that I have here.
>
> With the above, Linux v5.9 (no patches applied) idles at around 42mW
> (15mW goes to the serial device, so it's more like 27mW, anyway...).
>
> Linux v5.10 with the following two commits reverted (otherwise the
> system is not stable):
>
> * fb2c599f056640d289b2147fbe6d9eaee689f1b2 (ARM: omap3: enable off mode
> automatically)
> * 21b2cec61c04bd175f0860d9411a472d5a0e7ba1 (mmc: Set
> PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4)
>
> And the following config change on top of omap2plus_defconfig (to make
> OFF mode work on v5.10 as detailed in "Nokia N900 not hitting OFF mode
> since 5.9 is caused by proactive memory compaction"):
>
> > sed -i 's/CONFIG_COMPACTION=y/CONFIG_COMPACTION=n/' .config
>
> Idles at much more -- 60mW (compared to 42mW). Executing "rmmod
> panel-sony-acx565akm" makes the power draw return to v5.9 levels.
>
> I don't really understand why this would happen, and as stated before
> wasn't able to really bisect the problem. However, some simple guesswork
> led me to find that reverting 7c4bada12d320d8648ba3ede6f9b6f9e10f1126a
> ("drm/panel: sony-acx565akm: Fix race condition in probe") makes v5.10
> idle at 42mW again. I don't know if this because v5.9 never properly
> initialised the panel, or because the race condition fix introduced
> another problem that leaves the hardware in an abnormal state.
>
> Any hints on what could cause this extra power draw? Maybe the panel is
> waiting for something? I suppose it's potentially feasible that with
> more modules and userspace loaded the panel idles properly, but I
> currently don't have a way to measure that.
First of all: I do not have documentation for that panel. Before my
patch what happened was that gpiod_get() initialized the reset GPIO
as OUTPUT_LOW. Immediately afterwards it is configured as OUTPUT_HIGH
in acx565akm_detect(). So there are 2 options:
1. The reset GPIO was low before the driver probe starts. In that
case everything is fine with or without 7c4bada12d320 and there
is no expected change in behaviour. The GPIO is just toggled
slightly earlier.
2. The reset GPIO was output-high before the driver probe starts
(e.g. because bootloader used the panel, kexec, ...). In that
case the reset GPIO will be low for just a very short time (just
a few instructions). Usually panels have a minimum time required
for reset lines to be asserted. In acx565akm_power_off() it is
hinted, that 100ms should be ok.
My patch fixes the behaviour, so that reset is no longer asserted
for less than 100ms in the second case by not asserting it at all.
That also means, that the LCD is not reset when it has already been
configured before the probe routine is called. An alternative would
be the following patch, which does the reset and ensures minimum
reset times are ok:
------------------------------------------------------
git diff drivers/gpu/drm/panel/panel-sony-acx565akm.c
diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
index ba0b3ead150f..2a8c0f7342ce 100644
--- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
@@ -629,11 +629,12 @@ static int acx565akm_probe(struct spi_device *spi)
lcd->spi = spi;
mutex_init(&lcd->mutex);
- lcd->reset_gpio = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_HIGH);
+ lcd->reset_gpio = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(lcd->reset_gpio)) {
dev_err(&spi->dev, "failed to get reset GPIO\n");
return PTR_ERR(lcd->reset_gpio);
}
+ msleep(100); /* ensure minimum reset assertion time */
ret = acx565akm_detect(lcd);
if (ret < 0) {
------------------------------------------------------
-- Sebastian
>
> Regards,
> Merlijn
>
>
> PS: For both v5.9 and v5.10 kernels the only other change to
> omap2plus_defconfig is to make the watchdog(s) built-in.
Attachment:
signature.asc
Description: PGP signature
